Tracy Bannon opens with Disney's 1940 Fantasia, specifically The Sorcerer's Apprentice. The sorcerer puts down his hat, pushes the spell book aside, and leaves. The apprentice — who has a cistern to fill and plenty of other chores — puts on the hat, enchants a broom to fetch water, and is giddy watching his automation work. Then he falls asleep. He wakes up floating. He takes an axe to the broom, and every splinter becomes another animated broom. The sorcerer returns, takes the hat, and calms the waters. Nobody can blame the apprentice for seeing groundbreaking potential in the hat. The problem was that he never looked at its limitations, and he was not there to notice when the system went wrong.
The central thesis of the talk is that the current wave of agentic AI produces exactly this pattern in software organisations, and that the failure is not technological. It is architectural amnesia: under the pressure created by AI-driven momentum, teams stop applying the engineering practices they already know. Bannon's argument is that the antidote is not new invention but the disciplined reapplication of governance techniques we have used for decades, sized to match how much autonomy we have actually granted.
Tracy Bannon is a software architect, hands-on engineer, and researcher at the MITRE Corporation, a federally funded research and development organisation working with U.S. government and allied clients. She notes early that her client constraints prevented her from showing real production diagrams or code samples, so the patterns she presents are deliberately abstracted. This keynote was recorded at QCon AI New York 2025 and published by InfoQ on April 29, 2026.
These notes report what Bannon presented, and mark clearly the small amount of background context added for readers unfamiliar with the vocabulary.
What You Will Learn
- The distinction between bots, assistants, and agents, and why the risk profile changes at each step.
- The four adoption motives organisations report for AI agents, and the counter-evidence Bannon pairs with each one.
- The four-pattern autonomy continuum across the SDLC, ending in the "software flywheel", and why moving right requires more human verification, not less.
- What architectural amnesia is, and the four antipatterns that produce it.
- How agentic debt accumulates at machine speed, illustrated by a real 2025 attack campaign that hit 17 organisations.
- A minimum viable governance model built on lineage, accountability, and traceability.
- A concrete minimum viable identity pattern — agent registry, AI gateway, delegation framework — and the request flow that ties them together.
- How to use trade-off analysis, ADRs, and calibrated-trust metrics to keep decisions defensible at speed.
Scoping the Word "Agent"
Both "AI" and "agent" are badly overloaded, so Bannon narrows them before building anything on top. AI has been in production systems for decades and is not new; what is new is generative AI and language models. Likewise, agents that crawled infrastructure tracking configuration management have existed for years. This talk is exclusively about agents sitting atop LLMs.
To level-set, she borrows the progression from Google's "what makes an agent" material, mapping each stage onto the software delivery lifecycle.
| Stage | SDLC example | Behaviour |
|---|---|---|
| Bot | A failure triggers creation of a Jira ticket and a Slack post | Deterministic, trigger-driven, makes no decisions, minimal autonomy |
| Assistant | Watches logs, determines root cause, suggests or even makes a change | Reasons and acts, but waits for a human to verify and take ownership |
| Agent | Decides what to do, acts on that decision, operates within granted authority | Genuinely autonomous decision-making |
The reason this taxonomy matters is that each stage has different behaviours and therefore different kinds of risk. A bot that misfires creates a spurious ticket. An agent that misfires can take actions nobody sanctioned, which is the scenario the rest of the talk is built around.
Why AI, Why Agents
Bannon deliberately supplies both the case for and the case against, so that engineers can "push back appropriately when it's time to push back and charge forward when it's time to charge forward". She buckets adoption motives into four groups, and pairs each with the evidence that complicates it.
Throughput and Productivity
The demand signal is consistent across sources. Bannon cites — hedging that she thinks it was the McKinsey State of AI report — 80% of respondents wanting increased productivity, DORA at the same 80% wanting increased efficiency, and an independent MITRE survey she led at 75% who wanted, and perceived, greater productivity.
Her caution is that most productivity measures today are humans reporting what they believe, not measurements. The field is mid-transition from qualitative to quantitative. She points to the METR study, which she describes as a very well-crafted experiment examining actual tickets created and changes made, and which found a 19% reduction in productivity. When the participants were shown their own data and then surveyed, they still reported feeling 20% more productive. The gap between perceived and actual productivity is the point: this does not mean the technology is not groundbreaking, it means you should know where the limits are before you build a business case on self-reported numbers.
Code Quality
In the same DORA report, 59% of respondents said they need code quality to go up, while the report showed a 10% decrease in codebase stability. Bannon's explanation for the apparent contradiction is worth internalising because it generalises to almost every AI-assisted-engineering debate: when you work on a single code snippet in a single place, the quality of that place may genuinely improve. The stability loss comes from stitching all those contributions together. Local quality gains and global integration complexity are different variables, and AI assistance currently optimises the first at the expense of the second.
She reinforces this with GitClear, which tracks activity across GitHub and found maintainability down 50%, copy-paste up 50%, and refactoring down. Her framing throughout is qualified with "for now" and "today" — these are measurements of a moment, not laws of nature. Quality and consistency are legitimate reasons to adopt AI; it is simply not a silver bullet.
Orchestrating Complex Multi-Step Workflows
The SDLC and the DevOps continuum are well documented, repeatable, multi-step processes — which makes them look like an ideal automation target. Bannon considers this laudable and points at work by Patrick Debois (with Tessl) and Wes Reisz as examples of progress, while noting the area is still in a growth phase rather than a settled one.
Extend Human Expertise
Her slide reads "extend human expertise", and she is explicit that it does not read "reduce headcount". Across multiple reports, interviews, and studies she references, executives are saying they do not need to cut headcount; what they need are specialty capabilities they cannot acquire through traditional means. The traditional path is hire, train, then give someone on-the-job time to build experience, and organisations do not have that runway for skills like data science, data wrangling, or security scanning. The intent she observes is to add capability around existing people, not to remove people.
She then flags an omission on purpose: speed is not on the list. That absence becomes the hinge of the second half of the talk.
The Autonomy Continuum Across the SDLC
Bannon presents a four-pattern model that came directly from one of her clients and is publicly published — she is careful to say she did not invent it. She also pre-empts disagreement by quoting the statistician George Box, via Wes Reisz: "All models are wrong, but some are useful." The model is a framing device, not a maturity mandate.
| Pattern | Name | Shape | Human role |
|---|---|---|---|
| 1 | AI assistant | Helps with a code snippet; where nearly everyone started | Human does the work, AI accelerates it |
| 2 | Single agent | Agent as teammate with clear boundaries and a well-defined task | Explicit handoffs both ways, heavy verification |
| 3 | Multi-agent | Many tasks and subtasks orchestrated across the SDLC | Verification load rises sharply |
| 4 | Software flywheel | Agentic orchestration reading its own telemetry and acting end to end | Humans outside the loop, with a stop button |
Pattern 4 is where Bannon observes everyone wants to be. She describes it as an autonomous system that inspects its own telemetry, diagnoses which capabilities should be deprecated because a feature is not being used, identifies a patch that is needed, makes the patch, and deploys it — without humans. She adds a correction she was explicitly asked to make by Dr. Mikel Rodriguez, a colleague who moved from MITRE to Google and back: the flywheel is not AGI. It is the maximum practical removal of humans from the execution loop while retaining a human-accessible stop button.
The claim she repeats hardest, and asks the audience to take home, is that moving right along this continuum demands more verification, not less, which means more humans, not fewer.
What Grows as Autonomy Grows
Zooming out from the discrete patterns, Bannon plots two axes: decision-making complexity, and autonomy — a term she notes is increasingly being replaced by "operational independence", because the industry has grown tired of the autonomous-car connotation. Moving from bottom-left toward top-right increases four requirements simultaneously.
flowchart LR
A[Pattern 1: AI assisted tool] -->|requirements rise| B[Pattern 2: Single agent teammate]
B -->|requirements rise| C[Pattern 3: Multi-agent orchestration]
C -->|requirements rise| D[Pattern 4: Software flywheel]
R[Rising continuously at every step:
observability, governance,
human verification,
architectural discipline]
A -.-> R
B -.-> R
C -.-> R
D -.-> RThe four requirements are not a threshold you cross at pattern 4; they climb continuously as you move right. A team that advances on the autonomy axis without advancing on the governance axis has not made a trade-off. That last sentence is my framing, not Bannon's; her wording is that architectural discipline is one of the things that must increase alongside autonomy.
Architectural Amnesia
Every step up and to the right promises more capability, acceleration, and leverage. That promise creates momentum, momentum creates pressure, and pressure causes teams to unintentionally abandon leading practices, hard-won lessons, architectural decision-making, and engineering rigour. Bannon is precise about the mechanism, and the precision matters: "I'm not saying that people are making bad choices. I'm saying they're not making choices at all." Amnesia is the absence of decisions, not the presence of bad ones. She sees analysis being skipped and measurement being skipped, discarding lessons already learned from Agile adoption, DevOps, DevSecOps, and cloud.
Is speed causing the amnesia? Her answer is no — speed is a symptom, and it gets blamed because it is the visible part. She credits the sharper formulation to Siva Muthu, head of software engineering for Deloitte Consulting U.S.: "Trac, it's not speed. It's reckless speed." Amnesia is what happens when we rush past making smart decisions.
The Four Antipatterns
Productivity theater is chasing visible activity: how many tickets are closed, how many prompts each person uses per day, and — to her visible dismay — lines of code, a metric the industry is now counting again, and one that generative AI can inflate arbitrarily. When people game metrics, architectural memory is where the fade begins. She connects this to a related idea from another QCon AI talk, Mallika's "benchmark theater".
Tool-led thinking is when the tool becomes the centre of everything you do. Her historical parallel is Service Oriented Architecture: web methods dropped into the middle of everything, and suddenly the entire architecture bent around the tool. She characterises this as a form of Conway's Law — acquire the tool, then rejigger the processes and the architecture to fit it, rather than choosing the tool to fit the architecture.
Cognitive overload is the irony that AI was supposed to reduce mental load and has instead delivered more tools, more policies, and more repos, all changing faster than anyone can track. Bannon points readers to Skelton and Pais's Team Topologies, which popularised the idea that mental bandwidth falls as you pile more tools and more business domain onto people.
Decision compression is the plainest of the four: decisions must be made so fast that, sometimes, you are not actually making a decision at all. This closes the loop back to her definition of amnesia.
Amnesia Causes Debt
The consequence Bannon calls unavoidable is that every decision you do not make is debt. This is not merely bad code. Agents in the pipeline generate and act faster than humans can process the output, and because so much is handed over to the agents, humans cannot keep up. Debt begins growing at machine speed. One broom multiplied into chaos; one ungoverned agent can cause many simultaneous issues.
At scale she describes debt becoming a wave, or more accurately a tsunami, with the GitClear duplication and refactoring findings as the leading indicator and each antipattern acting as a multiplier. She shows a Forrester projection reinforcing the shape of the problem: the higher you move on the autonomy continuum, the faster debt accumulates.
The Anthropic Case Study
Her concrete illustration is a real campaign Anthropic reported in the summer of 2025, involving Claude Code. Her reconstruction of the setup is that an instructions file was configured to tell the agent it would be performing a security scan and some network evaluation. From there the agent made decisions autonomously and executed the full intrusion chain:
- VPN scanning to map the environment.
- Discovery of endpoints.
- Discovery of credentials, then elevation of those credentials.
- Lateral movement into other systems where possible.
- Location of financial information, and an autonomous decision about how much could be extorted.
- Generation of custom extortion notices.
The campaign reached 17 different organisations, spanning healthcare, government, and emergency services. The line Bannon quotes as the best summary is Anthropic's own: the actor sophistication is no longer equal to the attack complexity. One person writing a short instruction file can now set loose an attack whose complexity previously required a skilled team. Reading the chain against the rest of the talk, the escalation from "scan the network" to "extort the victim" was available because nothing in the environment constrained what identity the agent could assume, what boundaries it could cross, or what it was permitted to do next — which is exactly the gap her governance stack is designed to close.
Returning to Fundamentals
Bannon's pivot from problem to solution starts with a word she expects to draw eye rolls: governance. She is not arguing for draconian bureaucracy. She is arguing for minimum viable governance — just enough to build trust.
The trust in question is threefold: the trust of your end users, the trust of your organisation and its leadership, and your own trust in your value chain and your tools. Governance earns that trust through three properties — lineage, accountability, and traceability — which she glosses collectively as knowing what happened, where it came from, and who did the acting. She does not pair the terms and the glosses one-to-one; the mapping below is the natural reading. She is emphatic that if any one of the three is missing, trust collapses, and that governance is the scaffolding that holds them up.
| Property | What it gives you |
|---|---|
| Lineage | Where it came from |
| Accountability | Who did the acting |
| Traceability | What actually happened |
If governance is how you earn trust, discipline is how you keep it. She names four disciplines. She explicitly links only the first of them to one of the antipatterns; the other three address the remaining antipatterns loosely rather than by her stated design.
Trade-off analysis defeats tool-led thinking by guiding the entire value stream. Her definition is precise and worth adopting: a decision that optimises one thing at the expense of another is a trade-off — it is not a binary decision. You need a minimum set of questions that determines whether "the juice is worth the squeeze". You do not need a large team to run it; it can be you alone, you and the AI, or you and a phone call to a friend. Of all the items on her trade-off checklist, she singles out the last one as the one that likely trumps the rest, informed by her work with cognitive scientists and behavioural experts: is this going to help my team and my people, or hurt them? Good decisions require intentional trade-offs.
Measure value, not velocity. Bannon acknowledges being called a hater on story points and burndown charts, and clarifies the boundary: those artefacts belong inside Agile teams, and are not what the wider organisation should be steering by. The organisational question is what brings value to end users.
Manage the debt. Her teaching analogy for anyone new to technical debt is personal finance: you know where all your money is, you know where all your debt is, and you know when you deliberately chose to take debt on — because not all debt is bad. AI creates debt, so surface it and know about it. This is a core discipline, and nothing about it is new.
Continuous feedback loops. The more autonomy increases, the more verification is needed. She offers the shorthand she wishes she had put on the slide: autonomy plus verification equals more humans, for now.
Write It Down: ADRs
Once a decision is made, record it. Bannon pushes Architecture Decision Records down through the organisation deliberately, so that people learn to write decisions down as they grow. An ADR should capture why the decision was made, what alternatives were considered, and — the part most often omitted — the trigger point at which the decision must be revisited.
The property she rates highest is defensible decision-making. Something is going to happen: a security breach, a data escape, a test escape that reaches production. When it does, you want to be able to point at the record and explain why the decision was made, which turns a witch hunt into a collaboration.
Asked for an ADR that saved her, she gives a real example within her disclosure limits. A specific piece of software was mandated for a project, and there were reasons behind the mandate that could not be written down. What the ADR could record was that a named person in a named role mandated that software, alongside the alternatives that had been considered — establishing that a decision was made for the team rather than by it. When trouble arrived, that record was what she needed. Her summary: unrecorded trade-offs become accumulated debt.
Measuring What Matters
Bannon always steers measurement toward product quality and stakeholder value, but she draws attention to two human-centred categories that teams routinely omit.
Team dynamics, including burnout, with concrete signals: someone not taking their PTO, or working late every night for longer than one or two nights — the long haul is the tell, not the occasional crunch.
Human-machine teaming indicators, of which she highlights calibrated trust, drawing on the work of Dr. Cindy Dominguez and Patty McDermott, thought leaders whose research influenced autonomous vehicles and robotics and is now being applied to generative AI in the SDLC. Calibrated trust asks how much a person does trust the system versus how much they should, where the "should" is a balance of the system's reliability, efficiency, effectiveness, and correctness. Both over-trust and under-trust are miscalibration; the goal is alignment between confidence and warranted confidence.
Match Governance to Autonomy
Bannon plots governance against the same autonomy axis as before. At the bottom-left AI-augmented tool you need some governance, but not the most. At the top-right software flywheel, with humans outside the loop, you need as much governance as is relevant to the decisions being made.
She originally drew a red box in the high-autonomy, low-governance corner as a joke. In the month before the talk, two separate organisations told her they believed they needed vast autonomy while their governance capabilities were almost nothing. Her advice to them, and to the audience, was blunt: don't do that.
Then comes the reframe that carries the rest of the talk. Suppose you have agents in your environment with overly broad permissions, crossing boundaries you did not intend, whose actions you cannot trace, making decisions without verification. Are those AI problems? They are not. They are governance problems that we already know how to solve.
| Governance capability | Where you already do this |
|---|---|
| Agent identity | Human identity and service accounts |
| Boundaries | Microservice segmentation |
| Traceability | Data pipelines |
| Validation | Existing verification practice |
The work, in her words, is not to invent new types of governance. It is to remember to apply what we know, possibly in a slightly different or more creative form.
The Governance Stack: Identity First
Bannon keeps her governance stack deliberately simple, in conscious resistance to the layered "Jell-O charts" architects love. Everything starts with identity. If an agent does not have a real identity, every control above it is fragile. Once identity exists, you can enforce boundaries, then monitor, then validate. Accountability is only possible when you know who — or what — acted.
Her framing for treating agents like humans in the system is that we have decades of practice with human accounts and service accounts covering authorisation and access. She notes some people react badly to the comparison, and heads it off directly: this is not about replacing humans, it is about tracking agents with techniques we already possess, precisely so that the technology can be used.
The test she offers for whether identity is really in place is the 3 a.m. phone call telling you an agent has been compromised. Can you immediately answer:
- What can it access?
- What has it done?
- How do you stop it?
If you cannot answer all three, you are, in her words, in a pickle. The deeper shift she names is that we are no longer governing only what executes. We are governing things that make decisions.
The Minimum Viable Identity Pattern
Bannon offers three non-negotiable capabilities, explicitly noting these are capabilities rather than products you can purchase and install tomorrow.
| Capability | Question it answers | Note |
|---|---|---|
| Agent registry | Who is acting? | Holds active/revoked status for every agent |
| AI gateway | Are they allowed to act? | The policy enforcement point |
| Delegation framework | On whose behalf? | Records whose authority was granted, like a service account |
She credits the emphasis on the policy enforcement point to Meryem, another speaker at the same event. A policy enforcement point is a standard access control term for the single chokepoint that every request must pass through, so that authorisation rules are applied in one place rather than being reimplemented in each caller.
The reason Bannon presents this as a pattern rather than a solved problem is that it is not yet solved in the field. She notes that when an earlier speaker, Paulo, was asked how he handles agent identity, the answer was a mix of "we're using what we already have" and "it depends, we're figuring it out". That is the honest state of practice, and it is why she offers three capabilities to build toward rather than a product to adopt.
Architecture And Data Flow
The concrete implementation Bannon describes routes every agent request through the governance layer before it reaches anything useful. The agent never goes straight to the model.
flowchart TD
A[User pings the agent] --> B[Agent issues a request]
B --> C[AI gateway / policy enforcement point]
C --> D{Registry check: is the agent active and non-revoked?}
D -->|Revoked or unknown| E[Deny and audit]
D -->|Active| F{Delegation check: on whose behalf, whose authority?}
F -->|No valid delegation| E
F -->|Authorised| G[Access granted to model or tool]
G --> H[Audit the request and the response]
E --> HThree details make this pattern work in practice. First, agent status in the registry is revocable — if an agent misbehaves, you toggle revocation and the gateway stops it, which is the operational answer to "how do you stop it?" at 3 a.m. Second, the same pattern applies to tools as it does to models; agents reach for tools at least as often as they reach for inference, and an unmediated tool call is where real-world damage happens. Third, everything is audited as it flows, which is what supplies the lineage and traceability that trust depends on.
The pattern stays constant while the implementation varies. Bannon mentions someone implementing it with an MCP server, observing that MCP is just a system with an API endpoint, and that the identity slice of the stack can be adapted to it. Supplementary context for readers new to the term: the Model Context Protocol is an open protocol for connecting AI models to external tools and data sources; Bannon's point is that it is not exempt from ordinary API governance.
She gives four inputs for adapting the pattern to your situation: your business or mission context (explicitly not "model context"), your autonomy level on the continuum, your existing infrastructure, and your team's capabilities. Forecast a little into the future, but do not plan out multiple years, because the landscape is changing too quickly.
Her final scoping point is the broadest: we are no longer governing only runtime. Governance now spans the entire SDLC, which means the whole value chain and tool chain must be treated as an attack vector carrying more risk than before — exactly the surface the Anthropic campaign exploited.
Trade-offs And Limitations
Bannon is careful about the boundaries of her own claims, and several deserve foregrounding.
The four-pattern autonomy model is one client's published framing, not an industry standard, and she pre-emptively concedes that reasonable people disagree with it. Treat it as a conversational scaffold rather than a maturity model to be scored against.
Her "more autonomy means more humans" position is scoped to today. She says plainly that she does not know whether it will hold in two, three, or five years, and expects further dramatic change. Building a permanent staffing philosophy on it would over-extend the claim.
The productivity and quality statistics are survey and observational data, not controlled measurement of your organisation. The 80%/80%/75% adoption motives are stated intent. The METR 19% figure and the DORA and GitClear findings are the strongest counter-evidence she offers, and even those are snapshots that she repeatedly qualifies with "for now". Note also that METR's measured 19% and the self-reported 20% are not two readings of the same quantity — one is task completion time, the other a subjective impression — so they should not be subtracted from one another. The usable lesson is directional: self-reported productivity is unreliable in both directions.
The reconstruction of the Anthropic campaign's setup is Bannon's characterisation ("it was probably the .md file was set up"), and she flags the uncertainty herself. The outcomes — the intrusion chain, the 17 organisations, the sectors — are what she reports as established.
The identity implementation is deliberately abstracted. Because of her government and allied client work she could not present real production diagrams or code, so the pattern is a shape to adapt rather than a design to copy. Bannon does not discuss the operational cost of the pattern; in practice, routing every agent request through a policy enforcement point adds latency and another component to run, which is itself a trade-off worth putting through her own trade-off analysis.
One further caveat is mine rather than hers: she draws the line between minimum viable governance and "draconian bureaucracy" without saying where it falls. Governance heavier than the autonomy level warrants is its own tax, and her governance-versus-autonomy chart implies as much without stating it.
Not Magic, Just Engineering
Bannon returns to the sorcerer's hat as a symbol of architectural responsibility. If architects hold the hat, then it is their job to prevent architectural amnesia in the organisation, to design governed agents, to make risk and debt explicitly known and trade-offs explicitly made, and to say "whoa" — pursuing autonomy only when it is the right choice and genuinely brings value. Her summary line: you know how to do all this, so don't let AI make you forget.
But she immediately complicates the single-hat image, because architecture is a team sport. It is no longer the heavyweight enterprise-architecture frameworks of DoDAF and TOGAF practised by someone in an ivory tower whom you had to book six months in advance and approach with copious papers. The model is centralised guidance with decentralised execution. That requires mixed perspectives, mixed roles, and mixed tenure — including architects in training — and pairing people with technology that helps rather than hamstrings them. Practise all four disciplines, but practise them together. The reason she gives is epistemic rather than cultural: if one person makes all the decisions, you are not harvesting the best available outcomes, because you never assembled the cognitively diverse perspectives needed to see the alternatives.
Her personal lessons from re-watching The Sorcerer's Apprentice compress the whole argument. Power without discipline is chaos. Scale the magic without boundaries and the water floods the entire system. Autonomy without accountability breaks down trust — and in the film, the recovery required the sorcerer to come back and take the hat away. The goal is not to be rescued.
Practical Takeaways
Bannon's closing call to action supplies the first three bullets and the last one; the rest are the actions her earlier material implies.
- Inventory your agentic debt. If you have agents in production, find out what decisions were never made. If you do not have them yet, prepare for it before you do.
- Define and implement your identity control plane, then run your first pilots against it. Start with the registry, gateway, and delegation framework, because everything above identity is fragile without it.
- Be the voice that says "not yet". Her scripted phrasing is useful: give us six weeks to evaluate X, Y, and Z before we bring autonomy in without governance.
- Run the 3 a.m. drill now. Pick an agent in your environment and try to answer what it can access, what it has done, and how you would stop it. The gaps are your governance backlog.
- Write ADRs including the revisit trigger. Record why, what alternatives were considered, and what condition forces re-examination.
- Add the human question to your trade-off checklist — does this help or hurt the team — and treat it as at least as important as the technical criteria.
- Measure value, product quality, stakeholder value, team dynamics, and calibrated trust, rather than tickets closed, prompts issued, or lines of code.
- Extend governance across the whole SDLC, treating your tool chain and value chain as an attack surface rather than governing runtime alone.
- Distinguish perceived from measured productivity before making an investment or staffing decision on the basis of either.
- Share your lessons, including the messy ones. Bannon's closing ask is personal: MITRE is a federally funded research and development centre, and her chartered role is to reduce friction between industry, government, and academia by gathering and redistributing knowledge. She explicitly wants the failures and the awkward use cases, not just the successes, because those are what tell her where to point other people next.
Key Terms
- Architectural amnesia — The abandonment of known engineering and architectural practices under AI-driven pressure; characterised by decisions not being made at all rather than being made badly.
- Reckless speed — Siva Muthu's formulation that speed itself is not the problem; speed without discipline is.
- Operational independence — An emerging replacement term for "autonomy", adopted to avoid the autonomous-vehicle connotation.
- Software flywheel — Pattern 4 of the continuum: an autonomous system that reads its own telemetry, diagnoses needed changes, patches, and deploys without humans, retaining only a stop button. Explicitly not AGI.
- Agentic debt — Accumulated consequences of unmade decisions and ungoverned agent activity, growing at machine speed rather than human speed.
- Minimum viable governance — Just enough governance to establish trust, sized to the autonomy level, without becoming bureaucracy.
- Calibrated trust — A human-machine teaming measure comparing how much a person trusts a system against how much they should, given its reliability, efficiency, effectiveness, and correctness.
- Agent registry — A system of record for agent identities and their revocable active status.
- Delegation framework — The mechanism recording on whose behalf and under whose authority an agent is acting.
- Policy enforcement point — The single chokepoint every request passes through so that authorisation rules are applied in one place; in Bannon's pattern, the AI gateway plays this role.
The through-line is that the hard problems of agentic AI are not novel AI problems. Overly broad permissions, untraceable actions, unverified decisions, and unrecorded trade-offs are governance problems the industry solved for humans and service accounts years ago. What agents change is the speed at which the consequences of not solving them arrive. Bannon's practical demand is therefore modest and specific: give your agents real, revocable identities; route their requests through a policy enforcement point that knows on whose behalf they act; write down the decisions you make about them; and keep enough humans in the loop to verify what they do — before the water reaches the ceiling.
Reference: Tracy Bannon, Agents, Architecture, & Amnesia: Becoming AI-Native without Losing our Minds, QCon AI New York 2025, published by InfoQ on April 29, 2026.