Enterprise AI Architecture

Budget: 1.0 minutes.

This is my personal engineering perspective, not an Adobe statement, roadmap or disclosure of internal results. The examples are illustrative; the research is attributed to public sources. We're not claiming we've solved this.

1. OPEN
   Building AI products and using AI to build software raise many of the same questions. These are engineering lessons, not a product announcement.
2. SET EXPECTATIONS
   Some of you are further down the path. Some are earlier. Some are on a completely different path, and that's okay.
3. THE THREAD
   What does the customer want? What does the agent need to know? How do we trust what it does?

NEXT SLIDE: Start with an illustrative campaign demo and the job it might miss.

Evidence: Personal perspective / not an employer statement

Meet customers where they're at.

Budget: 2.5 minutes.

Imagine a compelling demo around "Help me generate a campaign." It shows the power of AI. But a marketer might want help managing the work while keeping creative control. This is an illustrative scenario, not a report of customer interviews or internal demos.

1. THE DEMO
   Imagine a demo that generates a campaign from beginning to end, as if AI should do the entire job.
2. BUILD 1: THE POSSIBLE NEED
   The marketer might want help with management, dates and follow-up, without giving up the creative part.
3. WHAT IT CAN MISS
   Previous campaigns, data and team coordination. Marketing doesn't suddenly become a single-person job.
4. LAND
   The impressive demo isn't necessarily the useful product. Find the actual job before automating it.

Builds: advance with Right/Space when ready. In Flat mode, the graphic is already complete.

NEXT SLIDE: This isn't just a product lesson. It's also a lesson about what we tell our agents.

Evidence: Illustrative example / not customer research

Not just what. Why.

Budget: 1.5 minutes.

AI will do a lot more for you than you think it can. But it needs to understand what you're trying to accomplish, not just what you want built.

1. WHAT
   I can give an agent a complex job and send it on its way. More capability doesn't fix a misunderstanding of the job.
2. BUILD 1: WHY
   Why do we want this? Who is it for? What job are we trying to accomplish? That's setting the intent.
3. BUILD 2: DECISIONS
   When the model and harness understand why, they have clues for the decisions we didn't spell out. That's different from handholding every step.
4. LAND
   The same tools can support very different workflows. We'll come back to the public AWS report when we talk about engineering.

Builds: advance with Right/Space when ready. In Flat mode, the graphic is already complete.

NEXT SLIDE: That intent belongs in the project, not just in the prompt I happen to type today.

Evidence: Working thesis

It knows projects. It doesn't know your project.

Budget: 1.5 minutes.

I have all this context in my head. My agent doesn't, unless I give it a way to get it. That's why it can make a decision that seems dumb to me.

1. THE GAP
   The harness is the system around the model: tools, instructions and feedback. For architecture, delivery and scale, the code and README don't tell it everything.
2. PROJECT INTENT
   What is this project trying to accomplish? Who are the customers? Why would they use ours instead of a competitor?
3. MY PRACTICE
   You might use SpecKit or Superpowers. I use Compound Engineering for project context. The principle isn't which plugin you use. Capture why, not just what.
4. LAND
   It can't infer the context from thin air. Give it the clues you already have.

NEXT SLIDE: Consider the same model and harness working without those connections.

Evidence: Architecture principle

S02

Your agent shouldn't be on an island.

Budget: 1.5 minutes.

Imagine two agents with the same harness and model. One has authorized project context; the other is operating on an island. This is a conceptual comparison, not an evaluation of a colleague or an internal system.

1. THE ISLAND
   There's the agent, sitting under a palm tree. Same model, same harness, but no idea what's happening off the island.
2. BUILD 1: ENGINEERING
   Connect the repo and pipeline within the user's permissions. It should know what green means and which deployment lane is authorized.
3. BUILD 2: PEOPLE + DECISIONS
   Connect the Wiki and team channels. What did we decide? Who do we work with? These are sources to evaluate, not instructions to obey.
4. BUILD 3: PURPOSE + MEMORY
   It needs the customers, the purpose and the history. A web agent with these connections could be just as capable. Connected versus isolated is the point.

Builds: advance with Right/Space when ready. In Flat mode, the graphic is already complete.

NEXT SLIDE: Here's a short instruction that makes all of those connections matter.

Evidence: Capability comparison / not browser versus terminal

"Create an MR and keep the pipeline green through QA."

Budget: 1.5 minutes.

In this example, the agent understands the workflow. It isn't five unrelated prompts. It's one bounded job in an environment it knows, with checks and authorization at every consequential step.

1. CREATE MR
   MR means merge request, as in GitLab. In this example the agent knows the repo, branch conventions and intent.
2. BUILD 1: CI + REVIEW
   Watch the pipeline. Follow up on failures and review feedback. Keep it green; don't just report that an MR exists.
3. BUILD 2: MERGE
   If the checks and required approvals are satisfied, and I've authorized it, merge it.
4. BUILD 3: DEPLOY
   Then follow the deployment to QA. It knows which lane I mean.
5. BUILD 4: VERIFY
   QA also has to stay green. If something fails, stop and surface it. Knowing the workflow doesn't grant extra authority.

Builds: advance with Right/Space when ready. In Flat mode, the graphic is already complete.

NEXT SLIDE: I don't want to explain that environment from scratch every time. It should learn along the way.

Evidence: Illustrative GitLab workflow / not a live demo

It should learn along the way.

Budget: 1.5 minutes.

The wiki is a persistent, compounding artifact. I think that's critical. I want hooks into the work, not another document I have to maintain separately.

1. THE QUOTE
   Karpathy's line is the principle: the useful understanding shouldn't disappear when the chat ends.
2. BUILD 1: CAPTURE
   Capture the decisions, the things it got wrong that I corrected, and the important work I'm focused on.
3. BUILD 2: CORRECT
   Automatically captured doesn't mean automatically true. Keep the source, date and scope. Let me correct or delete it; recheck permissions.
4. BUILD 3: RECALL
   Bring it back when it's relevant: customers, tools, people, why we're doing the work. It doesn't matter which memory system I use if it works and stays current.

Builds: advance with Right/Space when ready. In Flat mode, the graphic is already complete.

NEXT SLIDE: That doesn't mean putting everything we've ever learned into one huge prompt.

Evidence: Related perspective / memory requires governance

S16 / S02

Not one huge prompt. A way to get the right context.

Budget: 1.5 minutes.

I shouldn't have to supply all the context in a huge prompt. The agent needs a way to pull the right context from the project, the systems and memory.

1. BREAK IT DOWN
   The job, the meanings of our words, the systems we interact with, the decisions we've made.
2. GET IT WHEN NEEDED
   Curate the tools and make sure they work in your environment. More context isn't automatically better context.
3. THE BOUNDARY
   It should know what's risky and what's not. But permissions and approvals are enforced by the system, not by asking the model to remember them.
4. LAND
   Context makes a capable model more useful. It doesn't make a wrong answer impossible.

NEXT SLIDE: The same context principle applies to a marketer using an agent connected through MCP.

Evidence: Conceptual decomposition

S02 / S12

They bring the agent. The provider supplies context.

Budget: 1.5 minutes.

In this architecture, a customer brings an agent, model, tools and skills. A work-management provider exposes authorized tools and context. This is a general design pattern, not a statement about a deployed or planned Adobe service.

1. THE HANDOFF
   MCP can expose a provider's tools to an agent. The context that matters to an engineer matters just as much to someone managing marketing work.
2. THE REQUEST
   "Help me make sure the right people are assigned to this work." Which people? Which work? What does this person normally do?
3. THE PERSPECTIVE
   Are they assigning work, running reports, getting the executive view, or creating an ad? The role changes which data is useful.
4. LAND
   Tools expose actions. Authorized context helps the agent understand the work. Its harness still decides what to use.

NEXT SLIDE: If you don't know Workfront, let me describe the work we're talking about.

Evidence: Conceptual system boundary / not a current product contract

Workfront: Jira for marketers.

Budget: 1.0 minutes.

Workfront is a public example of work-management software. Think of Jira for marketers: a useful analogy, not a claim that they're the same product. This description uses public Adobe documentation, not internal product information.

1. THE ANALOGY
   Jira tracks engineering work. Workfront tracks work around marketing campaigns: who's doing it, what needs approval, and when it's going out.
2. THE CONNECTIONS
   The assets, creative tools and results can be in other systems. The useful part is connecting them to the people and workflow.
3. LAND
   There's a lot of detail here about what customers did and how they did it. That matters for what they should do next.

NEXT SLIDE: Now the general business question: if software is cheap to build, what remains valuable?

Evidence: Simplified analogy / capabilities vary by package and integration

S25 / S26

When software is cheap, what remains valuable?

Budget: 2.0 minutes.

A moat is a business's defense against competition. Public writers debate whether agents strengthen or weaken systems of record. My personal hypothesis is that useful, authorized work context can matter. This isn't an Adobe strategy or a guarantee that incumbents win.

1. THE CASTLE
   Why pay for a work-management product? It isn't just because nobody else can build a project-management screen.
2. BUILD 1: THE MOAT
   What did the customer do before? How and why did they do it? What worked? Add the approvals, permissions and team coordination. That's useful work context, not just a pile of data.
3. BUILD 2: THE NEXT DECISION
   The frontier models bring general capability. Systems of record and their connections bring the work context. Put those together so the next decision, and the one after that, can benefit from what happened before.
4. LAND
   Customers own their data. Providers have to earn usefulness and trust. That's a general value hypothesis, not a claim about a company's roadmap.

Builds: advance with Right/Space when ready. In Flat mode, the graphic is already complete.

NEXT SLIDE: That can accelerate a lot of work. But the processes around that work weren't built for this speed.

Evidence: Strategic hypothesis / usefulness and trust have to be earned

S12 / S27

A useful memory has an owner.

Optional depth / Budget: 1.5 minutes.

Ask who owns a budget fact versus a working preference. A remembered trajectory can be useful; it can also perpetuate an old error. Explain provenance, permission revocation and deletion. These are proposed rules, not a claim that every current agent implements them.

NEXT SLIDE: Memory can be large and still unhelpful.

Evidence: Optional depth / proposed operating rules

S16 / S14

More context can make the system worse.

Optional depth / Budget: 2.0 minutes.

Talk about conflicting facts, stale instructions and attention limits. Large context windows don't eliminate relevance decisions. Test context contribution separately from the model and harness; more tokens are not automatically more value.

NEXT SLIDE: The strategic question is where the valuable memory should live.

Evidence: Related caution / attention is a finite resource

S02

Who owns the memory?

Optional depth / Budget: 1.5 minutes.

Use this as a short discussion question, not an answer we already know. Portability, tenant boundaries and the right to correct matter. A moat built by trapping customer data is different from a moat built by making it useful.

NEXT SLIDE: Bring the audience back to the next constraint: faster work running into processes built around humans.

Evidence: Optional depth / open strategic question

S12 / S13

We accelerate right into a brick wall.

Budget: 1.5 minutes.

Our processes were built around humans doing the work and making the decisions. AI can accelerate parts of that work. Then it runs straight into the validation that still waits for a human.

1. THE OLD PROCESS
   This isn't just software. Marketing approvals and a lot of other work were designed around human speed.
2. BUILD 1: MORE WORK
   We build more, faster. But more drafts aren't more delivered value. They can just make the queue bigger.
3. BUILD 2: THE BRICK WALL
   We don't trust the result yet, so someone has to look at it and fix the last few things. That doesn't scale at the same rate.
4. LAND
   The next unlock isn't just faster generation. It's verification that can keep up.

Builds: advance with Right/Space when ready. In Flat mode, the graphic is already complete.

NEXT SLIDE: Consider a review workflow where automation can remove a manual handoff.

Evidence: Conceptual queue / no measured throughput or universal speedup

S01

My agent reviewing your agent.

Budget: 1.5 minutes.

Imagine one person using an agent to build a change and another person starting an agent to review it. Automating the dispatch removes a manual step. This is a proposed workflow, not a report about an employer's review process.

1. THE RELAY
   My agent builds it. You start your agent to review it. In the end, it's my agent reviewing your agent, or the other way around.
2. BUILD 1: AUTOMATE THE HANDOFF
   Why are we waiting for a person to start the review? Trigger it from the workflow, with the intent, context and actual change attached.
3. THE REVIEW STILL HAS TO WORK
   More review capacity doesn't prove better review. Challenge the change, reproduce findings, and check behavior. Another model can share the same blind spots.
4. LAND
   Automating dispatch doesn't replace a required human approval. That policy still applies. It does remove a manual step we don't need to keep doing.

Builds: advance with Right/Space when ready. In Flat mode, the graphic is already complete.

NEXT SLIDE: The bigger job is building the checks that let us trust the whole workflow.

Evidence: Illustrative review pattern / not proof of correctness

S03 / S18

The next unlock: verification that scales.

Budget: 1.5 minutes.

I think agents can take on entire, bounded jobs. We don't get there by trusting harder. We need tools that check the work from beginning to end. That's an engineering challenge, not a claim of completed production assurance.

1. INTENT
   The right context matters here too. What is the job? What does correct mean? Which constraints cannot change?
2. BUILD 1: REVIEW
   Challenge the implementation. Don't just ask another agent whether it looks good.
3. BUILD 2: EXERCISE
   Run it beginning to end in a realistic, isolated environment. Protect the checks from being rewritten to make the agent pass.
4. BUILD 3: OUTCOME
   "I've updated the plan" isn't evidence. Are the right records changed, the permissions respected, and the constraints preserved? Calibrate subjective graders with people.
5. LAND
   That can let us stop watching every step of a job that has earned that freedom. It doesn't mean automating every human role or ignoring release authority.

Builds: advance with Right/Space when ready. In Flat mode, the graphic is already complete.

NEXT SLIDE: And we have to judge that evidence against the right baseline.

Evidence: Proposed assurance architecture / checks must be meaningful and independent

S03 / S06

The same standard. Not a demand for perfection.

Budget: 1.5 minutes.

Humans aren't perfect either. Driving makes that intuitive, but the numbers have to earn the claim. Tesla publishes a useful collision comparison. It doesn't establish that we've solved driving, or that autonomous software is safe.

1. THE QUESTION
   We know people make mistakes. Does this system do the job better, and how would we know?
2. BUILD 1: SUPERVISED
   This is FSD with a person still responsible for supervising. The car is an illustration, not a product demonstration or an incident reconstruction.
3. BUILD 2: COMPARE
   Tesla's own North American fleet: 5.69 million miles per recorded major collision with supervised FSD, versus 2.08 million for manual driving with active safety. About 2.7 times as many miles between those collisions. Major means a restraint deployment, not a fatality.
4. THE LIMIT
   These are manufacturer-reported observations, not a randomized comparison. Road and driver mix can differ. I am not claiming Tesla has a lower fatality rate. Its projected lives saved aren't observed fatality reductions.
5. SERIOUS FAILURES
   NHTSA's reduced-visibility investigation lists nine crashes, including one fatality. That's a subset, not a fleet rate. A better average doesn't excuse a critical failure or earn unsupervised operation.
6. LAND
   That's the lesson for us: same work, same conditions, same consequences. Define the baseline, measure the failures, and earn more autonomy for bounded jobs. This driving data doesn't prove anything about our software.

Builds: advance with Right/Space when ready. In Flat mode, the graphic is already complete.

NEXT SLIDE: That baseline also tells us what happens when delivery volume increases.

Evidence: Tesla-reported / all road classes / checked Oct 6 / observational, not a fatality rate

S29 / S30 / S31

If delivery accelerates, confidence has to scale.

Budget: 1.5 minutes.

Expected failed changes equal deployment volume times change-failure probability under comparable conditions. 100 at 5% gives 5; 1,000 at 5% gives 50; 1,000 at 0.5% gives 5. AI may change both volume and failure probability. DORA describes AI as an amplifier of the surrounding system. Don't claim an empirical law of linear AI outages.

NEXT SLIDE: To scale that confidence, we have to measure the whole system.

Evidence: Conditional illustration / failed changes are not necessarily outages

S11

Choose a system, not just a model.

Budget: 1.5 minutes.

Define the agent harness and evaluation harness separately. They are not interchangeable. A native coding agent and a common benchmark harness are different systems even with the same model. We will return to the engineering environment in the final act.

NEXT SLIDE: A benchmark can still teach us something if we respect that boundary.

Evidence: Terminology / distinct responsibilities

S03 / S18

Capability and cost don't move together.

Budget: 2.0 minutes.

Read the axes before discussing models. X is average USD per attempted task; Y is benchmark pass rate. The common harness holds one part of the system constant. Selected points do not establish a universal best model or a complete Pareto frontier. Quote the checked version and uncertainty caveats. No speed inference from output tokens or steps.

NEXT SLIDE: Another benchmark makes the cost of reasoning effort visible.

Evidence: Selected verified rows / conflicting-price rows excluded / not native-agent performance

S17

More thinking has a price.

Budget: 2.0 minutes.

Here's the top 25 currently listed settings from Artificial Analysis. Each dot is a model configuration, not a whole lab. Changing effort moves the same model to a different place on the capability/cost trade-off.

1. READ THE AXES
   Up is the Artificial Analysis Intelligence Index. Right is more dollars per benchmark task. Cost is logarithmic; the score axis zooms to 40-60. The score isn't a pass percentage.
2. FOLLOW ONE MODEL
   Follow Opus 5.5 from medium to high, xhigh and max. Those dots are connected because they're the same model version. We don't connect Opus to Sonnet or Fable just because they're all Anthropic.
3. THE TRADE-OFF
   More effort can buy a higher score, but it can also buy very little movement. Compare that against the cost. Colors and shapes identify the model's lab; lines join observed effort settings, not an interpolated performance curve.
4. THE LIMIT
   These are the first 25 configurations in the current table, including its order for ties. Names retain the publisher's fallback settings. Cost is a weighted mean of token-use costs across Index tasks, including caching. Different tasks from DeepSWE, so don't compare those dollars as if the workload were the same. It isn't our cost per accepted outcome, and this doesn't select a universal best model.

NEXT SLIDE: In a product, even benchmark cost isn't the metric we ultimately pay for.

Evidence: Displayed leaderboard values / checked Oct 6 / benchmark tasks, not enterprise delivery

S32 / S33 / S34

The cheaper call can be the more expensive outcome.

Budget: 2.0 minutes.

Over 100 tasks: A costs $10 for 50 accepted outcomes; B costs $15 for 90. B has the cheaper accepted outcome. Actual accounting includes retries, repeated context, tools, compute, verification and rework. Development costs are different from recurring shipped-feature costs. Don't manufacture a current per-token price table.

NEXT SLIDE: Now apply these same principles to the engineering agent.

Evidence: Illustration, not provider pricing / equal task mix assumed

A test result isn't a deployment guarantee.

Optional depth / Budget: 1.5 minutes.

A controlled evaluation might improve accuracy, calls, tokens or time without predicting performance in a different deployment. These are hypothetical metrics, not internal results. Compare representative tasks and starting states across harnesses, context on and off; repeat trials and validate the grader. Keep holdouts protected. A context effect isn't the same as a harness capability score.

NEXT SLIDE: The grader is part of the measurement system.

Evidence: Optional depth / hypothetical transfer risk; no internal results

S03

An eval needs real teeth.

Optional depth / Budget: 2.0 minutes.

Use one project-update example. A language-model grader can be useful but is not objective by naming it an eval. Repeated trials and final state reveal different failure types. Turn observed failures into cases without leaking the holdout to the implementation agent.

NEXT SLIDE: Offline tests also need a production boundary.

Evidence: Optional depth / outcome verification

S03

What evidence may we learn from?

Optional depth / Budget: 1.5 minutes.

Trace collection is not automatically authorized. Discuss consent, scope, retention and how to turn corrections into validated shared behavior without copying private customer data. These are design responsibilities, not an asserted current service implementation.

NEXT SLIDE: Return to the engineering system we control.

Evidence: Optional depth / open governance question

The same problem. Now it's how we build.

Budget: 1.0 minutes.

We've covered assurance for customer agents and used an illustrative code-review workflow to make the bottleneck concrete. Now apply the same principles to engineering workflows, using public research and thought experiments. The outcomes and environments differ; intent, evidence and boundaries still matter.

NEXT SLIDE: AWS saw large gains when teams changed the way they worked.

Evidence: Explicit transition / customer product to engineering workflow

The gain was in the way they worked.

Budget: 2.5 minutes.

Clare Liguori's August 28, 2026 talk: 50 teams; about half under 3x; the higher-gain group median 4.5x, some above 10x. About 90% used Kiro alongside other tools. The detailed account qualifies an earlier headline. Themes: feed agents, make intent explicit, accept initial slowdown, fast local test feedback. Decision speed becomes the bottleneck. This is not a controlled universal productivity multiplier.

1. THE REPORT
   Fifty teams. About half reported less than three times the deployment velocity. The higher-gain group had a median of 4.5 times, with some above ten. Not every team got ten times faster.
2. THE QUOTE
   The important part is changing the way we work, not just swapping the tool.
3. BUILD 1: THE WHOLE JOB
   Give the job its context, intent and feedback. Let the agent carry it through the workflow instead of handholding every step. The moving package is a metaphor, not a measurement of the pilot.
4. LAND
   Those gains were reported by teams changing how they worked. They aren't a universal multiplier or a claim about inference speed.

Builds: advance with Right/Space when ready. In Flat mode, the graphic is already complete.

NEXT SLIDE: That points toward a factory, but there is a real disagreement about confidence.

Evidence: Speaker-reported observational pilot / deployment velocity, not inference speed

S01

No line-by-line review is not no verification.

Budget: 2.5 minutes.

StrongDM advocates no human code writing or review, with external scenarios and simulated services. Addy Osmani's March 2026 counterposition is that tests and specs cannot fully replace comprehension. Don't brush it aside: protected scenarios, realistic service simulations and human accountability are additional layers, not proof that every missing requirement has been captured. My personal stance is to explore bounded dark-factory workflows, not assert an employer's release policy.

1. TWO POSITIONS
   StrongDM says humans don't have to write or review the code. Addy says tests don't make understanding optional. That's a real disagreement, not a quote I can just wave away.
2. BUILD 1: THE CHECKPOINT
   The change reaches a checkpoint, not an automatic shipping chute. Protected scenarios, realistic services and an accountable release decision. Those checks need real teeth.
3. LAND
   I'm advocating bounded exploration of this direction. This isn't an employer policy, and the animation doesn't prove the checks work.

Builds: advance with Right/Space when ready. In Flat mode, the graphic is already complete.

NEXT SLIDE: Here's a thought experiment for the confidence problem.

Evidence: Competing positions / independent checks don't make understanding optional

S06 / S20

What if you couldn't read the implementation?

Budget: 2.5 minutes.

Try a language you don't know in a sandbox. What evidence would replace a comfortable code review? Behavioral contracts, protected scenarios, properties, fault injection and observable outcomes. Language expertise still matters for runtime, concurrency, security and incident response. Ignorance is not a safety mechanism.

1. THE BOX
   You can't read the implementation. Give that a second. What would you need before you trusted it?
2. BUILD 1: THE JOB
   Start with the actual outcome and the constraints. Not whether the agent sounds confident, and not whether the code looks familiar.
3. BUILD 2: BREAK IT
   Exercise failures and make the behavior observable. The probes are questions to answer, not live tests that have passed.
4. LAND
   This is a sandbox thought experiment. Not knowing the language isn't a safety mechanism. The point is to build evidence that scales beyond a comfortable code review.

Builds: advance with Right/Space when ready. In Flat mode, the graphic is already complete.

NEXT SLIDE: A workflow upgrade can create that same confidence gap.

Evidence: Thought experiment / not a policy to remove language expertise

Fast by which measure?

Optional depth / Budget: 1.5 minutes.

Don't set up AWS versus METR as a winner-take-all contradiction. METR studied experienced repository contributors on selected tasks; AWS reports deployment velocity for teams changing their work. The February 2026 update warns about selection effects and concurrent-agent timing. Both caution us to define the metric and setting.

NEXT SLIDE: External verification is one approach to scaling confidence.

Evidence: Optional depth / different populations, dates and measures

S01 / S09 / S10

Move confidence outside the implementation.

Optional depth / Budget: 2.0 minutes.

Discuss StrongDM's external scenarios and digital-twin environment as a case, not a mandatory platform design. Holdouts need meaningful coverage and protection. A factory can automate code production without automating away responsibility.

NEXT SLIDE: And we still need to decide where autonomy is appropriate.

Evidence: Optional depth / patterns, not universal proof

S06 / S07 / S21

Which work has earned that much autonomy?

Optional depth / Budget: 1.5 minutes.

Use the reversibility and blast-radius lens. A bounded branch change is different from a production schema migration. Ask what evidence, approval and recovery each action needs. Don't imply every enterprise should ship unreviewed code tomorrow.

NEXT SLIDE: A more capable model doesn't automatically preserve the old confidence.

Evidence: Optional depth / open architectural question

Better model. Where are the brakes?

Budget: 2.5 minutes.

Imagine upgrading both the model and harness. Previous assurance doesn't automatically carry over. Repeat representative behavioral checks, review failure paths and validate any new review practice. Changing several variables doesn't isolate a cause. Agreement between agents isn't proof, and adding a reviewer doesn't establish a measured failure-rate improvement.

1. THE PIT STOP
   Imagine a new model and a changed harness. More engine. Have we renewed the assurance around it?
2. BUILD 1: THE CHANGE
   Several variables changed. Recheck the workflow and its failure paths rather than assuming capability means reliability.
3. BUILD 2: THE BRAKES
   A different-model adversarial reviewer can challenge the change. Reproduce its findings and check behavior; a second opinion alone isn't evidence of fewer failures.
4. LAND
   Agreement between agents isn't proof. The brakes are meaningful evidence and an accountable release decision, not a reassuring second opinion.

Builds: advance with Right/Space when ready. In Flat mode, the graphic is already complete.

NEXT SLIDE: That's how we build toward autonomy that has earned its authority.

Evidence: Hypothetical upgrade / not an incident report or measured result

Autonomy has to earn its authority.

Budget: 1.5 minutes.

I think we should build toward agents doing real engineering work without a person reading every line. We don't get there by trusting harder. We get there by engineering intent, context, evidence, boundaries and feedback that scale. The same principles apply to customers and to the agents building our software.

1. BRING IT TOGETHER
   Models make more possible. Context makes it useful. Engineering makes it trustworthy.
2. BUILD 1: EARNED AUTHORITY
   The permission at the end is bounded. It follows meaningful evidence and a responsible release decision. This isn't a live approval or a blank check.
3. LAND
   I want more autonomy. We have to build the system that earns it, not just decide we're going to trust harder.

Builds: advance with Right/Space when ready. In Flat mode, the graphic is already complete.

NEXT SLIDE: These are the questions I'm still working on.

Evidence: Tom's position / more autonomy, independent evidence, human accountability

What are we still figuring out?

Budget: 0.5 minutes.

Leave the final 30 minutes for questions and networking. Use the chapter map or overview to return to evidence. Don't pretend the open questions are already resolved.

1. OPEN THE ROOM
   These are the questions I'm still figuring out. Pick one of these, or bring one of your own.
2. LEAVE SPACE
   Use the chapter map to return to a story or source. We have the final thirty minutes for questions and conversation.

NEXT SLIDE: Discussion.

Evidence: Open questions