A talk by Matt Gibiec of Dynatrace, recorded at the AI Engineer World's Fair 2026, arguing that AI coding agents need real environment context (how services actually run) rather than working blind. Covers agent loops, operational and security risks, measuring agent value, and scenarios including bringing production dependencies into local testing, catching issues before users notice, suggesting fixes that account for the wider system, and planning before prompting with a human approving the final fix. Introduces Bluebox by Dynatrace, an observability agent for coding agents, as presented by the speaker; product claims are the speaker's and were not independently verified in the record. # Video Identity Observations ## Source Video **Title:** "Your AI Agent Has No Nervous System — Matt Gibiec, Dynatrace" ## Speaker Self-Description - The speaker explicitly identifies himself and his role: > "My name is Matt Gibiits and I'm the regional director of solutions engineering for AI native at Dynatrace." - He characterizes his employer: > "We are an observability platform, AI powered observability platform, but we're not going to be talking much about Dynatrace today." - He cites personal experience: **"I've been doing observability now for 8 years."** - He attributes a framing quote to his CTO: *"a quote from my CTO, Bernd"* — "agents operate at speed… without sight." ## Intended Audience (Demonstrated In-Room) The session is delivered to a **developer/engineering-leadership conference audience**, confirmed by live audience polling: > "How many developers do I have in the room… Any team leads? … Do I have a head of engineering in here?" The pain points raised map directly to that audience: looping agents consuming tokens, operational/security concerns, and whether "the agent bring[s] value to our users." ## Claimed Scope of the Talk - Explicitly **not a product-only pitch** at the outset: *"what we want to address today is a little bit different topic"* — the argument that agents fail without environmental context. - Central thesis, stated as a maxim: **"context is king"** — context is *"that nervous system that we… can provide to your agents."* - The talk pivots to promoting **Blue Box by Dynatrace**, described as *"an agent that will now be able to be integrated in the middle of any of your life development life cycle to provide context to any of your AI coding agents."* - Closing call to action: *"you can go ahead and go to bluebox.ai, and you can actually sign up for a preview of it."* ## Observable Presentation Patterns - **Vendor thought-leadership format**: problem framing (agents lack context, hallucinate, break dependencies) followed by a product solution, ending with a preview signup. - **Claimed capabilities** (creator claims, not demonstrated): production context in local testing, service/dependency mapping, early issue detection via historical baselines, remediation guidance, and *"plan before you prompt"* briefing. - **Human-in-the-loop positioning**: *"if we just let our agents do everything, I think it'll be a pretty messy world"* — control is retained by the human at deployment. - Stated goal: **"we want to help agents ship code you trust to production."** ## Boundary Note All audience-reaction and product-capability statements are claims made in a single conference talk; no independent verification or channel-wide conclusions can be drawn from this video alone. # Delivery Observation — "Your AI Agent Has No Nervous System" (Matt Gibiec, Dynatrace) ## Overall Communication Style The delivery is **audience-interactive, question-driven, and conversational**. The speaker structures the talk around a series of rhetorical and literal questions to the room, then pivots into product framing. He explicitly de-emphasizes the vendor pitch early on: > "We are an observability platform, AI powered observability platform, but we're not going to be talking much about Dynatrace today." ## Recurring Teaching Habits ### Show-of-hands polling A signature habit — used at least five times as a transition or engagement device: > "With a show of hands, anybody knows what Dynatrace is?" > "With a show of hands again, how many developers do I have in the room in here?" > "Anybody experience that? Everybody has, right?" > "Anybody in here having operational issues with your agents? Here and there, maybe." He often answers his own polls to validate the room ("That was a layup, right? I think everybody Everybody raised their hand in here"). ### Rhetorical question loops He asks a question, pauses, then answers it himself, frequently with "right?": > "But how do you measure value? Do you have instructions already today to how to measure value of your AI agents? No, right?" > "I think it'll be a pretty messy world, right?" ### Concrete relatable scenarios He anchors abstractions in developer pain points: > "you test it locally, and it works great. Locally, everything works great, right? We're happy, it's awesome. And then what we do is we merge to to a main branch, we push it out there, and all of a sudden three other services are broken. Has that happened to any of you?" ## Vocabulary and Phrasing - **Repetition of "context"** is the dominant lexical pattern — "context is king," "that connective tissue of a context," "using the context of your environment," repeated many times as the core message. - **Metaphor consistency:** the title's nervous-system metaphor is carried through ("context is... that nervous system that we that you can provide to your agents"). - **Catchphrase-style closers:** "context is king," "plan before you prompt," "ship code you trust to production." - **Repeated intensifiers:** "super, super important," "the very buzzy word out there like hallucinations." - **Role-based address:** tailors questions to segments of the room — "how many developers," "Any team leads?", "Do I have a head of engineering in here?" ## Structural Patterns - **Time management is explicit and frequent:** "it is 11:10 so officially time for our session," "we only have 18 minutes left in here," "we have 5 minutes." - **Signposted slide transitions:** "let's break this down," "let's shift to another question," "Let's take a look at another um example," "as we dive into the next um scenario." - **Escalating product arc:** the talk moves observe → detect → suggest fix → human control, framed as "We'll We'll first start with observe... then we detect issues, we'll be able to actually suggest fix... Lastly, we'll be able to drive the entire SDLC." - **Soft-sell close:** a direct CTA with QR codes and a preview signup, but delivered informally — "I also have my back pocket little um things that you can scan." ## Tone - **Casual and self-deprecating filler is common** — heavy use of "um," repeated words ("we we," "that that"), and hedges, consistent with live unscripted speaking. - **Enthusiastic/affirming:** "Okay, perfect," "it's awesome," "honestly one of my favorites." - **Personal credibility offered briefly:** "I've been doing observability now for 8 years." ## Uncertainty Notes - The transcript appears to have some gaps (e.g., between timestamps [912] and [934]), so Q&A delivery cannot be observed. - Single-video evidence means repetition counts reflect **one talk only**; habits like show-of-hands polling and "context is king" phrasing look characteristic here but cannot be confirmed as stable across other appearances. # Observation Record: "Your AI Agent Has No Nervous System" — Matt Gibiec, Dynatrace ## Speaker Identification - **Matt Gibiec** — identified in the transcript as "regional director of solutions engineering for AI native at Dynatrace." Sole substantive speaker. - **Bernd** — referenced only as Gibiec's CTO, via a quoted slide (full quote not read aloud; only the blue-highlighted portion discussed). - An audience member gives a brief non-substantive response ("Mhm") at the end. ## Central Thesis Gibiec argues that **AI agents lack a "nervous system"** — i.e., they lack the contextual awareness humans use to adapt — and that this gap can be addressed not by making agents more human-like, but by supplying them with **environmental context**. > "Context is king. And what context is, it is that nervous system that we... can provide to your agents." He frames agents' reasoning quality as strictly bounded by their data: > "These agents today are only as good as the data that is available to them to make... a decision." ## Claims and Stated Reasoning ### 1. Agents fail without adaptive reasoning - **Claim:** Agents like Claude get stuck in repetitive loops, consuming tokens without producing desired results. - **Stated reasoning:** A human researcher who gets poor results "will change your approach... approach it from a different angle," but agents today are "not smart enough to do that." ### 2. Value measurement is missing - **Claim:** Organizations deploying agents generally lack defined measures of agent value. - **Stated reasoning:** He reports asking audiences whether they have "instructions already today to how to measure value of your AI agents" and receiving "No." He argues engineering resources are being spent without success metrics, so teams should "take a little pause." ### 3. Missing context produces hallucinations and low-value automation - **Claim (attributed to CTO Bernd's quote):** Agents "operate at speed... without sight." - **Stated reasoning:** If data provided to agents lacks context, details, or permissions, teams enter "hallucinations" and "automate things in your environment that now probably don't bring in value." ### 4. Blue Box by Dynatrace as the proposed solution Gibiec presents **Blue Box** as an agent-integration product providing context within the development lifecycle. Claims made for it: - **Dependency awareness:** Brings "services and dependency mapping" and "production context into your local testing" to prevent cases where code works locally but breaks other services after merge (a failure mode he says developers commonly experience). - **Early issue detection:** Uses historical data and historical loads to establish "what normal looks like," flagging deviations (slower services, new errors) before they impact users — presented as the universal observability goal from his 8 years in the field. - **Change correlation:** Integrates with code repositories to overlay change data, so issues can be traced to "a merge that wasn't successful" or a pushed change. - **Context-aware remediation:** Because fixing one line of code may affect the rest of the environment, fixes are framed within dependency context. - **Planning ("briefing agents before building"):** "Plan before you prompt" — using existing environmental context to define what a new feature needs before development begins. - **Human in the loop:** Automation culminates in suggested fixes, with humans retaining the final decision to push. His stated view: "if we just let our agents do everything, I think it'll be a pretty messy world." ### 5. Closing pitch - "We want to help agents ship code you trust to production." - Preview sign-up promoted at **bluebox.ai**. ## Qualifications and Observational Notes - Gibiec explicitly stated the session would **not** focus on Dynatrace generally, positioning Blue Box within the broader agent-context argument. - His central claims about Blue Box capabilities are **promotional/product claims** delivered in a conference pitch setting, presented as future/preview capabilities ("you can sign up for a preview") rather than demonstrated results. - The CTO quote is only partially conveyed (highlighted text only); the full quote is not in the transcript. - Audience hand-raise responses (developers, team leads, one head of engineering, widespread experience with agent loops and security concerns, absence of value metrics) are reported by the speaker as evidence but are informal and unverified. - No counterarguments or dissenting positions appear in the transcript; the session presents a single advocacy position. # Speaker Attribution and Provenance Record ## Video Identification - **Title (metadata):** Your AI Agent Has No Nervous System — Matt Gibiec, Dynatrace - **Video ID:** 01a15ca6-e167-7277-aab3-420619238221 - **Content type:** Conference session recording (transcript only; the conference name and date are not stated, except that the session is on "the last day of the conference," a Thursday) ## Speakers and Roles ### Primary Speaker (Presenter) - **Name:** Matt Gibiec (per title metadata) - *Transcript variant:* "Matt Gibiits." The discrepancy is a likely transcription error; the title spelling is treated as the identity source. - **Stated role:** Regional director of solutions engineering for AI native at Dynatrace - **Stated employer affiliation:** Dynatrace - **Self-reported experience:** Eight years in observability (the speaker's own claim, not independently verified) - **Speaking role in session:** Presenter and product pitch delivery; addresses audience directly and runs audience polls by show of hands ### Referenced Individual (Not a Speaker) - **Bernd, CTO of Dynatrace** (identified as "my CTO, Bernd") - Quoted via a slide. The speaker says he will not read the full quote and highlights only part of it. - Quoted text read aloud: > "The agents operate at speed." > "...without sight." - The full quote is not in the transcript. Attribution rests on the speaker's statement that it is from his CTO. ### Unidentified Speakers - **Audience members** responded to show-of-hands prompts. No individual is identified, and no audience statements are attributed. - **Unidentified voice** at the end of the transcript (marked "Mhm" after a speaker-change marker). Identity and role are unknown. ## Referenced Sources and Third-Party Mentions - **Claude (Anthropic model):** Named as an example AI agent. The speaker references the user experience of repetitive looping and token consumption. These are presented as general observations, not cited studies. - **Customer experiences:** The speaker refers to "customers" generally ("I see customers spending 3 days..."). No specific customers are named. - **Audience experience:** Show-of-hands responses (developers, team leads, head of engineering, security concerns, operational issues). Results are not quantified in the transcript. - **Industry terminology:** "Hallucinations" is referenced as a "buzzy word." No source is cited. - **No formal citations, papers, or external data sources** are named in the transcript. ## Promotional Content > **⚠ PROMOTION FLAGGED** - **Product promoted:** Blue Box by Dynatrace (also written "Bluebox" in the transcript) - **Promotional elements:** - Extended product pitch covering multiple feature scenarios - Call to action: sign up for a preview at **bluebox.ai** - Physical materials: scannable items distributed by the speaker - **Speaker's affiliation with promoted product:** Employed by Dynatrace, the company that produces Blue Box - **Dynatrace's own description:** The speaker describes Dynatrace as "an observability platform, AI powered observability platform," and states the session will not discuss Dynatrace much. ## Availability and Limits - **Comment availability:** No comment data supplied in metadata. - **Curated metadata:** Only the title is provided. No speaker bio, description, timestamps, or chapter markers are available. - **Visual materials:** Slides are referenced ("on the right," "this slide," "this picture") but are not included. Slide content is only partly recoverable from spoken descriptions. - **Q&A:** The speaker offered time for questions. The transcript records "No questions?" and a brief unidentified response. No audience Q&A content is present. - **Transcript quality:** Contains a transcription variant in the presenter's name, inconsistent product naming, and some incomplete or repeated words. ## Provenance Summary | Category | Present in Source | Notes | |---|---|---| | Presenter identity | Yes | Title and transcript; name spelling differs | | Presenter role | Yes | Stated by speaker | | Employer affiliation | Yes | Dynatrace | | Promotional content | Yes | Flagged above | | Referenced quotes | Partial | CTO quote only partly read | | Formal citations | No | None identified | | Audience identities | No | Unidentified | | Comment availability | No | No data supplied | | Slide materials | No | Referenced but not provided | \>\> All right, it is 11:10 so officially time for our session. Thank you so much everybody for joining. I know this is the last day of the conference so I really appreciate for for all of you that that actually wanted to come on Thursday and and listen to our topic. My name is Matt Gibiits and I'm the regional director of solutions engineering for AI native at Dynatrace. With a show of hands, anybody knows what Dynatrace is? All right, we got a we got a couple hands, okay. We are an observability platform, AI powered observability platform, but we're not going to be talking much about Dynatrace today. Because what we want to address today is a little bit different topic and the topic that I want to address is, as you see the title of the session, that your AI agent has no nervous system. Probably an intriguing title and you're thinking, well, of course it doesn't have a nervous system, it's it's not a person. Well, but if you really think how AI agents are being used today, we are using these agents to replace things that people used to do. And a lot of times, in order to do that, we need the reasoning. And when we really think about it, if we need reasoning, we need these agents to be able to actually not necessarily behave like humans, but have enough input to understand what they need to do to actually help us in our organization and not just automate things that aren't necessarily working very well today. So, with that said, let's let's break this down. With a show of hands again, how many developers do I have in the room in here? Okay, perfect. Any team leads? Okay. And okay, the last one might be a little bit tougher. Do I have a head of engineering in here? Would would you call yourself a head of engineering? All right, perfect. I got one. So, if you take a look at these questions, we're not going to go through all of them. We only have 18 minutes left in here. But, if you take a look at these questions, has any of you ever ask yourself a question or been asked a question, why am I stuck in a loop with my agent? How many of you have used, for example, Claude, and it just keeps repetitively doing the same thing over and over, consuming tokens, not giving you the result that you want? Anybody experience that? Everybody has, right? Now, if you think about it from a human perspective now, if you as a human do research, and you get results that that are not what you want, you will change your approach. You approach it from a different angle. But, our AI agents today, they're not smart enough to do that. All right, let's let's shift to to another question in here. I like the one under team lead in the middle. How can I handle operational issues? Are you thinking about that yet today, or right now are you still in the boom of let's just get things deployed, let's just get get things going, and we'll figure out everything else later? Anybody in here having operational issues with your agents? Here and there, maybe. Okay, uh let me throw a twist in here. How about security concerns? That That was a layup, right? I think everybody Everybody raised their hand in here. And so, again, a a very important questions that we have to ask ourselves. And the last one that I want to try with you guys, let's look at the the head of engineering in here. I love the middle one again. Does our app or does the agent bring value to our users? I think we we jumped in so quickly to the AI world and at the AI era that a lot of the times I see customers and and spending 3 days in here talking to folks, everybody has that AI buzz, this AI agent buzz, but how do you measure value? Do you have instructions already today to how to measure value of your AI agents? No, right? And and I almost think that as much as you want to run fast and get there, we have to take a little pause and understand what are we really trying to accomplish and how can we measure the success of our agents? Because if we're spending our engineering resources, time, effort, money on creating these agents and and and utilizing them in a way that we believe helps our organization, we need to come up with measures that'll help us do it. Now, with all these questions, hopefully I I I I set up a picture a little bit in here to to to really jump into the next topic that I want to discuss, which is led in here by a quote from my CTO, Bernd. And I'm not going to read the whole thing, but just highlight what we see in blue in here. The agents operate at speed. Would everybody agree with that? That they're pretty fast? But without sight. And what what we mean by that is these agents today are only as good as the data that is available to them to make the reason to make the reasoning to make a decision. If the data that is provided to our agent is missing context, is missing details, is missing the right permissions to pull the data from some of the tools in your environment, you start entering the the very buzzy word out there like hallucinations. You start doing processes and automating things in your environment that now probably don't bring in value because there's not enough context in your environment. So, what if I told you that essentially what we want to do in here is we actually don't need your agent to necessarily have nervous system or sight to be efficient and be productive. There's obviously a little twist on the title of the session in here. But what they need is actual context of your environment. You can pick any agent that that that's out there. You can just pick the the easy scenario of Claude and trying to automate things with um Claude inside of your um SDLC life cycle. And as you do that, if Claude doesn't have access to the context of your environment, if it is not able to understand the dependencies of your services, if it is not able to understand how your applications are being used by your users, it will start coming up with decisions and advices that might seem right at that point, but they won't be right in the long term because there's not enough context for that agent to understand how your environment really looks like. So, what I want to sum up this slide with is this one sentence in here, context is king. And what context is, it is that nervous system that we that you can provide to your agents. So, as they're communicating, as you're automating things, as you're creating new processes, that connective tissue of a context is driving all of the processes that you're automating with your agents. So, let's take a let's take a look at a couple examples. So, keeping that in mind, what what what I want to present to you is Blue Box by Dynatrace. And what a Blue Box is is essentially an agent that will now be able to be integrated in the middle of any of your life development life cycle to provide context to any of your AI coding agents or other proprietary agents that you're developing in your environment. I have a couple slides that we're going to go through in here. I'm not going to go through every single scenario in here, but I'm going to point out the most important things that that I believe are helpful in here. Let me Let me run this scenario by you. How many times you as a developer develop a feature, maybe even develop a feature or skill for an agent, and you test it locally, and it works great. Locally, everything works great, right? We're happy, it's awesome. And then what we do is we merge to to a main branch, we push it out there, and all of a sudden three other services are broken. Has that happened to any of you? Where your impact, even though locally it worked fine, once it was merged with other agents, with other applications, now it broke a process in your environment. That is one of the most important things that Blue Box by Dynatrace can provide in here. We will be able to bring that essentially services and dependency mapping for every single one of your agents, every single one of your AI workloads. So, as you're developing and as you're making changes, you're not just talking about testing things locally. We'll actually be able to now use Blue Box to bring the production context into your local testing. So, now you know whether the feature that you develop not only works locally for you and what you're trying to automate, what you're trying to achieve, but also that it won't break and impact negatively anything else that that your agent that your workload is connecting to. Let's take a look Let's take a look at another um example in here. I This is honestly one of my favorites just in the entire world of observability. I've been doing observability now for 8 years, and I think if there's one goal that I ask any of my customers, like, what would you like to achieve with your observability strategy with now AI? And when it comes to issues, I think this is everybody will say that. Find issues before they're real issues, before they impact my organization, before they impact my users. This is now exactly what the context that Blue Box brings into your agents will be able to do for you. And how do we really get that done? We are able to now again understand end-to-end the interactions of your agents within your application, within your ecosystem, within your organization. And what we are able to do is we are able to use the historical data from your environment, the historical the historical loads to understand what regular what normal looks like. So, when things start to deviate from what normal looks like, we are able to now get ahead of it and inform your agents, let's say in your IDE for your developers, that one of the services that belongs to them now it's acting slower or all of a sudden it's throwing errors that it didn't throw. Now, what Blue Box will also do will be also integrated in the middle of your code repository. So, as you do that, we will now also have the context of what was changed in your ecosystem. What was changed in your application? What was changed in your workload? So, now be able to overlay that data and understand that the issue that might be happening in your environment was actually caused by a change that somebody pushed out there. Maybe by a merge that wasn't successful. Okay? So, as we dive into the next um scenario in here, we discovered an issue. We We started with creating context, right? So, we have the context of your environment. We're able to bring literally production context data to your local testing, to your developers in their IDE. You bake in Blue Box into your AI coding agents. Now, we're able to detect the issues early. We're able to start to be product proactive. But, what's next? We have to talk about fixing things. And here's yet another example where Blue Box will be able to be directly baked in into your SDLC. So, when we detect that there is an issue, when we know and we have the knowledge of your repo, we know who pushed it, we know what changed, we are now able to again once again provide the context to your developers and let them know that the service that is now having an issue, that the agent that is now having an issue, that the workload that is now having an issue can be remediated in the following steps. So, again, why is the context so important in that process? Because when we need to fix a bug that's causing an issue in our environment, it is it might be changing one line of code to fix that particular issue. But after you change that one line of code, what happens to the rest of your environment? What happens to the rest of your application? So, again, that context and the dependency of all the other services in your environment is super, super important. So, as we do that, as we think about fixing things, it's not only about fixing the the issue that we have at hand, but also making sure that we don't cause any other issues in our environment. Um and the last um um or or two more suggestions that I want to run through is actually briefing your agents before building starts. That's actually, I think, one of one of my favorites when it comes to directly talking to the developers. I think the way too often we see developers going out there, and somebody came up with a feature, and now the developers just go and develop it. But have we done any research up front to understand what actually that feature needs to deliver to our users? What are we actually trying to accomplish with with that specific feature? That's exactly what we'll be able to to do in here. We'll be able to actually plan before you prompt. So, when you're building your agents, when you're building your applications, when you're using your AI coding agents, again, Blue Bags will bring in all that context from your application today, from all the from all the agents that you already have in your environment today, to understand that as you're planning for a new release, as you're planning for a new feature, you'll have enough data to understand what that feature that you're now focusing on needs to encompass. And the last scenario that I that I want to share with you guys is that at the end of the day, providing context to these agents can further drive automation. But when we talk about further driving automation, I'm sure some of you start thinking about the concept of human in the loop. Like at the end of the day, if we just let our agents do everything, I think it'll be a pretty messy world, right? At some point, we want to be able to have control over what we are doing in our environments. So, obviously, with Bluebox, you'll be able to do that as well. And I I I'd like this picture that we have in here on the right, right? We'll We'll first start with observe. Observing your environment, building that context, building that dependency mapping, providing that locally to your developers as they're testing, given all the production data, given all the production um details that they need to properly test their code. Once you have that, and then we detect issues, we'll be able to actually suggest fix, but not just fix for the particular issue that's breaking the agent, but using the context of your environment, using the context of the application that's monitored, using the context of the agents that are being monitored, making sure that the fix actually addresses what's happening in your environment. Lastly, we'll be able to drive the the entire SDLC in here by providing the fix, and giving you the control at the end of it, to make the decision whether you want to push the feature out there, whether you want to push the fix fix out there, or not. So, with that said, um that really brings me to the to the end of our um our a little pitch about uh Bluebox. And And what I like to finish with is we want to help agents ship code you trust to production. So, if this is interesting to you, um you can go ahead and go to bluebox.ai, and you can actually sign up for a preview of it. Um uh as as soon as you do that, we'll be reaching out to you to give you access to the platform. I also have my back pocket little um things that you can scan, so I'll just walk around the room now and give them to you. But, with that said, we have 5 minutes. So, if you there's any questions that that anybody wants to ask, uh we can absolutely use that time for those as well. No questions? \>\> Mhm.