# Your AI Agent Has No Nervous System Matt Gibiec, Dynatrace | AI Engineer World's Fair 2026 | 15:35 Source: https://www.youtube.com/watch?v=YNT7Plf9KIg Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/your-ai-agent-has-no-nervous-system Published: 2026-10-08 Tags: agents, coding-agents, human-in-the-loop, observability, testing ## TL;DR - AI agents work quickly but make poor decisions when they lack context about the environment they are changing. - Bluebox by Dynatrace brings production dependencies, usage patterns, and change data into coding and testing workflows. - Agents can suggest fixes, while a human keeps the final decision about whether code or remediation reaches production. ## Summary Matt Gibiec argues that AI agents need environmental context to reason well. Without information about service dependencies, application usage, permissions, and recent changes, an agent can repeat failed approaches, hallucinate, or make a change that works locally while breaking other services. He presents Bluebox by Dynatrace as an observability agent that provides this context inside the software development lifecycle. Bluebox can bring production dependency information into local testing, detect deviations from normal behavior before users notice, connect an incident to a code change, and suggest a fix that considers the wider system. Gibiec also describes using historical usage data to brief an agent before a developer starts building a feature. The proposed workflow begins with observing the environment, then supplying context, detecting issues, and suggesting remediation. Gibiec keeps a human involved at the final release decision, rather than allowing the agent to push every change automatically. ## Key ideas ### Agents repeat failed approaches when they cannot learn from their environment [02:08](https://www.youtube.com/watch?v=YNT7Plf9KIg&t=128s) Gibiec describes a common failure mode with coding agents such as Claude. An agent can keep doing the same thing, consuming tokens without producing the requested result. A person who gets poor research results usually changes approach, while current agents may continue repeating the same process. Gibiec connects this behavior to missing input about the system in which the agent operates. The agent needs enough information to reason about what it should do rather than simply automate the next available step. ### Operational and security problems appear when teams move faster than their measurements [02:47](https://www.youtube.com/watch?v=YNT7Plf9KIg&t=167s) Gibiec asks teams to consider operational issues and security concerns alongside deployment speed. He also questions whether organizations know how to measure the value of their AI agents. Teams may spend engineering time, money, and effort on agents without defining what success means. His recommendation is to pause and decide what the agent should accomplish, then create measures for that outcome. The concern applies to developers, team leads, and engineering leaders who are adopting agents before they understand their effect on users and operations. ### An agent is only as good as the data and permissions available to it [04:25](https://www.youtube.com/watch?v=YNT7Plf9KIg&t=265s) Gibiec describes agents as fast but blind when they lack the data needed for a decision. Missing context, missing details, or missing permissions to retrieve information from tools can lead to hallucinations and low-value automation. An agent working in a software development lifecycle also needs to understand service dependencies and how users interact with applications. Without that information, a decision may look correct at the moment but fail over the long term because the agent does not understand the wider environment. ### Bluebox brings environment context into coding-agent workflows [06:34](https://www.youtube.com/watch?v=YNT7Plf9KIg&t=394s) Gibiec introduces Bluebox by Dynatrace as an agent that can sit within the development lifecycle and provide context to AI coding agents or other agents built by a company. The context includes service and dependency information, application behavior, historical data, and changes in the code repository. He presents this as the connective information that allows an agent to reason about the system it is modifying instead of treating a task as isolated code generation. ### Production dependencies can be used during local testing [07:29](https://www.youtube.com/watch?v=YNT7Plf9KIg&t=449s) A feature can work on a developer's laptop and still break three other services after it is merged. Gibiec says Bluebox can provide service and dependency mapping for agents and AI workloads, then bring production context into local testing. That gives the developer information about whether a change works for the immediate task and whether it negatively affects connected workloads. The proposed test therefore includes the surrounding environment rather than only the local behavior. ### Historical behavior can expose problems before users experience them [09:09](https://www.youtube.com/watch?v=YNT7Plf9KIg&t=549s) Bluebox can use historical data and historical load to establish what normal behavior looks like. When a service begins acting more slowly or starts returning errors it did not previously return, the system can inform an agent in the developer's IDE. Gibiec also describes connecting this operational data with repository information, including what changed and who pushed it. That combination can indicate that a problem came from a code change or an unsuccessful merge before the issue becomes visible to users. ### A fix needs to account for the services around the failing component [10:59](https://www.youtube.com/watch?v=YNT7Plf9KIg&t=659s) After detecting an issue, Bluebox can use repository knowledge to tell developers how the affected service, agent, or workload might be remediated. Gibiec warns that changing one line may fix the immediate bug while creating another problem elsewhere. Dependency information allows the proposed fix to consider the rest of the application and environment. The aim is therefore to address the detected issue without ignoring the effects of the change on connected services. ### Agents can be briefed with usage data before development starts [12:09](https://www.youtube.com/watch?v=YNT7Plf9KIg&t=729s) Gibiec says developers often receive a feature request and begin building without first researching what users need the feature to deliver. Bluebox is intended to support planning before prompting by bringing in context from the existing application and agents. This information can help define what a new release or feature needs to include. The agent receives information about current behavior before it is asked to generate code, rather than discovering the system only after implementation. ### Humans retain the release decision [13:29](https://www.youtube.com/watch?v=YNT7Plf9KIg&t=809s) Gibiec describes a workflow that starts with observing the environment, building dependency maps, and giving developers production details during testing. Once an issue is detected, the system can suggest a fix based on the monitored application and agents. The final step is human approval. A person decides whether to push a feature or fix into the environment. Gibiec presents this control as a limit on fully automatic changes, while still allowing the agent to support more of the development lifecycle. ## Notable quotes - "The agents operate at speed. But without sight." (04:25) - "Context is king." (06:36) - "We will be able to bring the production context into your local testing." (08:24) - "We are able to use the historical data from your environment, the historical loads to understand what normal looks like." (09:39) - "At the end of it, you have the control to make the decision whether you want to push the feature out there, whether you want to push the fix out there, or not." (14:21) ## Tools & references mentioned - Dynatrace - Bluebox by Dynatrace - Claude ## Who should watch - You are using coding agents and seeing them repeat failed actions, consume tokens, or make changes without enough system information. - Your local tests pass, but merges or releases sometimes break connected services and you need production dependencies in the development workflow. - You are deciding how much autonomy to give agents and want suggested fixes with a human approval step before release. ## Editor's note Matt Gibiec says a feature can work on a developer's laptop and still break three other services after it is merged. Kitaru records the agent's model calls and tool results from a real run, then replays the run after a code change with the same inputs and responses, without touching real systems. That gives the team a repeatable check for whether a change alters an agent run that used to work. Written by the AIE Talks editors (the Kitaru team), not by the speaker. ## Related talks - [Your agent is blindfolded](https://aietalks.com/talks/your-agent-is-blindfolded) (Johan Lajili, Poolside, 09:58) - [Your Agents Lack Context: Here's How to Fix "You're Absolutely Right!"](https://aietalks.com/talks/your-agents-lack-context-heres-how-to-fix-youre-absolutely-right) (Brandon Waselnuk, Unblocked, 14:09) - [Your Attention Is the Bottleneck, Not Your Agents](https://aietalks.com/talks/your-attention-is-the-bottleneck-not-your-agents) (Zack Proser, WorkOS, 25:17) - [Why (Senior) Engineers Struggle to Build AI Agents](https://aietalks.com/talks/why-senior-engineers-struggle-to-build-ai-agents) (Philipp Schmid, Google DeepMind, 10:40) - [Realtime multiplayer, automation, and you!](https://aietalks.com/talks/realtime-multiplayer-automation-and-you) (Idan Gazit, GitHub, 21:41)