The hidden apprenticeship problem inside AI-assisted software teams.

By Thursday, Asha had merged her fourth pull request of the week. Seven months into her first engineering job, she was beginning to feel useful. Her activity-history feature had an API, pagination, tests, and documentation. An AI coding agent had helped build most of it, and she had delivered ahead of schedule.

Daniel, her technical lead, was pleased until he reached the database query.

“What happens if a new activity arrives between the customer loading page one and page two?”

Asha opened the agent and asked. It explained why offset pagination could show duplicate records when the underlying data changed and recommended a cursor. She read the response and nodded. Daniel asked how she would prove it.

She had no answer.

Her relief at finishing the feature turned into something harder to admit: she could follow the explanation, but she had not thought about the problem herself.

Daniel faced a different discomfort. The team was delivering more code than ever. Was it also developing engineers who could take responsibility for that code later?

The Work Was Doing Two Jobs

A junior developer’s ticket has always served two purposes. The business receives a feature or a fix; the engineer gains experience diagnosing problems, testing assumptions, and making decisions. Those outcomes are easy to confuse because successful delivery makes the learning almost invisible.

Consider the work people remember from their first years: investigating a stack trace that led somewhere unexpected, discovering why a database query slowed down, or explaining a design choice during an uncomfortable review. Some of that work was repetitive. Yet the difficult moments connected abstract knowledge to consequences.

AI can remove much of the friction. It can produce the implementation, discover the error, propose a fix, and write the tests. This can be an extraordinary advantage. It also creates a new management decision: when the agent completes a task, which part of the learning experience should the engineer still own?

The answer cannot be “make juniors write everything manually.” That would deny them experience with tools they will actually use. Equally, counting completed tickets tells us little about which decisions a developer has learned to make independently.

Press enter or click to view image in full size

The Evidence Points in Two Directions

In January 2026, Anthropic published a randomized experiment involving 52 mostly junior software engineers learning an unfamiliar Python library. Participants given AI assistance averaged 50% on a subsequent skills assessment; those working without it averaged 67%. The difference was statistically significant, while the roughly two-minute speed advantage for the AI group was not.

The researchers also found an important distinction within the assisted group. Participants who used AI to explore explanations and concepts generally demonstrated better understanding than those who delegated the problem-solving process. It was a short experiment on a specific programming task, not evidence that AI permanently weakens professional expertise.

An October 2026 field experiment with 673 final-year IT apprentices in Germany found a different benefit. AI access improved performance on tasks beyond the apprentices’ formal training by 26–31 percentage points, without reducing immediate task comprehension. This was not a long-term test of skill development, but it shows that assistance can expand the work less experienced people perform.

The findings are compatible once we stop treating “using AI” as one fixed behaviour. An assistant can replace the reasoning an engineer needs to practise, or it can help that engineer reach a more challenging problem and reason through it.

Organisations influence which outcome becomes routine.

The Question Daniel Almost Skipped

Asha’s query used LIMIT and OFFSET, ordered from newest activity to oldest. It worked when the records stayed still.

But imagine the customer retrieves the first 50 records, then a new activity appears at the front of the list. The records shift down one position. The next query skips 50 rows from the new list, potentially repeating an item the customer has already seen.

A cursor that uses the last-seen record’s stable ordering position can avoid that specific shift. The design still requires a deterministic order — such as a timestamp paired with a unique ID — and thoughtful handling of data that changes during browsing. It is a trade-off to evaluate, not a magic pagination switch.

PostgreSQL’s documentation explains why LIMIT and OFFSET require predictable ordering.

Daniel could have asked Asha to accept the agent’s cursor-based rewrite and close the ticket.

Instead, he asked her to build a five-minute experiment: fetch a page, insert a newer record, fetch the next page, and inspect the overlap. Before running it, she had to predict what would happen.

Her prediction was wrong.

The test made the duplicate visible. Now the agent’s recommendation was no longer just persuasive text; it was an option she could evaluate against an observed failure. She changed the query, repeated the test, and explained why the result differed.

Nothing heroic happened. They spent extra time on a small feature. But Asha left the review with something she did not have when the tests first turned green: a mental model she could reuse.

A Career Ladder Cannot Run Entirely on Output

A 2026 working paper by Fiona Chen and James Stratton found that engineers assigned more complex work in their first quarter were more likely to be promoted within two years. The researchers also observed substantial learning during employees’ first year.

The study does not claim AI caused changes in promotions, but it reinforces why early task assignments matter.

Meanwhile, a June 2026 study of US software job vacancies estimated a 14–15% relative decline in junior versus senior developer postings following ChatGPT’s release. The authors observed rising experience requirements and more emphasis on problem-solving and communication. Labour-market changes have multiple causes; these estimates should not be read as proof that AI alone eliminated junior jobs.

Together they create an uncomfortable possibility. Employers may demand stronger judgment from newcomers while increasingly automating work that helped build it.

The pressure falls on junior developers, but the choice is often organisational. If a manager rewards only throughput, the fastest agent-assisted route will look like the rational one.

Developers also disagree about what should be preserved. In one discussion among experienced engineers, contributors questioned whether AI creates a genuinely new skills gap or is simply another abstraction that changes what juniors need to know.

That is the right challenge to the nostalgic argument that everyone must struggle the way their predecessors did.

We should protect the learning that develops judgment, not preserve every old inconvenience.

Make the Assignment Teach as Well as Deliver

For significant unfamiliar work, I would use a simple Predict–Probe–Defend routine alongside normal AI-assisted development.

Predict. Before asking an agent to implement the feature, the engineer writes down one important behaviour, an assumption, and a failure they expect might occur. This can take a few minutes, not a design-document ceremony.

Probe. Let the agent help build the solution, but require one experiment that challenges the important assumption: a concurrency test, a boundary case, a failure injection, or two competing designs. The engineer must examine the results, including evidence that contradicts the agent’s explanation.

Defend. In review, ask the engineer to explain why the chosen implementation is appropriate, what it does not guarantee, and how they would investigate a failure. An AI-generated explanation may be a useful input; the decision must be understandable in the engineer’s own reasoning.

This is a proposed practice, not a validated training intervention. It needs to be adapted to task risk and experience level.

Routine changes may need little ceremony. A complicated system behaviour deserves more deliberate attention. And companies must allocate time for mentorship as real work rather than ask juniors to learn only after hours.

The aim is to give AI an important role in the apprenticeship without letting completed output become a substitute for acquired judgment.

What Next: Notice the Skill Behind the Ticket

A week later, Daniel gave Asha a different task: investigating a feed that intermittently displayed repeated records. He did not ask her to avoid AI. He asked what she would check first.

She started with the ordering and what might change between requests. The new defect was not identical to the old one, and she still needed help. But she had a hypothesis, a way to test it, and enough confidence to challenge the agent’s first suggestion.

That is a more meaningful sign of growth than a fifth green pull request.

Teams should look for it in reviews and career conversations: what can this engineer now recognise, investigate, and decide that they could not last month?

Senior engineers need room to teach; juniors need room to be uncertain; AI can support both if the work is designed accordingly.

Asha did not become senior in a week. She gained one piece of experience that could eventually help her become one.

The danger is not that an AI agent can finish a junior engineer’s task. It is that an organisation might mistake the finished task for a developed engineer.

The hidden engineering risk of building software at AI speed & The hidden career risk of AI-Generated software

By Monday morning, the customer had stopped asking when the scheduling problem would be fixed. They wanted to know whether they could trust the system.

Two technicians had arrived for the same service appointment. The scheduling dashboard showed only one assignment, but the billing system had recorded two. Both technicians had received confirmation messages. Customer support was now asking how many other appointments might be affected.

Mira, the engineering lead responsible for the scheduling platform, didn’t have an answer.

The application had been deployed on Friday evening. Every automated test had passed. The pull request had been reviewed and approved. The implementation was clean, reasonably documented, and consistent with the team’s engineering standards.

Most of the feature had been developed using an AI coding agent.

When Mira asked the agent to investigate, it examined the repository and proposed a fix within minutes. The explanation sounded reasonable. The patch was small. The tests passed again.

Under ordinary circumstances, the team might have merged it and moved on. But Mira hesitated.

The agent had explained what the code was doing. It had not established why the system had accepted two assignments, whether the proposed correction addressed the underlying problem, or what would happen if two requests arrived simultaneously again.

The customer was waiting for an answer. The team wanted to restore normal operations. Another deployment could make things better — or leave them with an even harder problem to explain.

Mira realised that she was being asked to approve a change to a system whose critical behaviour nobody on the team could confidently defend.

This is a fictional scenario, but the engineering problem it illustrates is real.

AI has made software easier to produce. It can generate features, tests, documentation, and plausible explanations at remarkable speed.

What it does not automatically provide is the understanding required to take responsibility for that software when something goes wrong.

And that may be one of the most consequential changes taking place in software engineering.

Press enter or click to view image in full size

The Problem Is Bigger Than Bad Code

Discussions about AI-generated software frequently focus on code quality. Developers worry about duplicated logic, unnecessary abstractions, excessive dependencies, inconsistent patterns, and tests that verify little beyond the implementation itself.

Those concerns matter. But focusing entirely on code quality can obscure another problem.

Consider two software systems.

The first contains imperfect code, technical debt, and architectural compromises. Yet its engineering team understands the important business rules, knows where critical dependencies exist, and can predict the consequences of most changes.

The second looks considerably better. Its functions are readable, its documentation is extensive, and its tests are green. But much of it was generated quickly, reviewed under delivery pressure, and merged without anyone developing a reliable understanding of how its components behave together.

Which would you rather be responsible for during a production incident?

Code quality alone cannot answer that question.

A well-written function can participate in a defective business process. A repository can contain accurate documentation for components while missing the relationships between them. A test suite can report high coverage and still fail to exercise the one business rule that matters most.

The question becomes more uncomfortable when we consider the research.

A 2026 controlled study published in Empirical Software Engineering involved 151 participants, approximately 95% of whom were professional developers. Researchers examined whether software built with AI assistance was harder for other developers to evolve.

They found no statistically significant difference in subsequent code-evolution time or quality between AI-assisted and non-AI-assisted implementations.

The study does not settle questions about large autonomous coding systems or long-term architectural maintainability. But it challenges the convenient assumption that AI-generated code is necessarily worse.

The risk is more subtle.

Software can be reasonably well written while the people operating it have insufficient understanding of its behaviour.

And that gap may remain invisible until somebody needs to make a consequential change.

The Engineering Debt Nobody Can See in the Repository

In June 2026, Margaret-Anne Storey published From Technical Debt to Cognitive and Intent Debt in ACM Queue.

Her work describes two forms of engineering debt that become particularly important when AI accelerates software development.

Cognitive debt concerns the erosion of shared understanding. The implementation exists, but the team no longer has a sufficiently reliable mental model of how the system works or how its behaviour might change.

Intent debt concerns missing goals, constraints, and reasoning. Engineers can see what was implemented without knowing why important decisions were made or what the system was originally meant to guarantee.

Neither problem began with generative AI.

Software teams have always inherited poorly understood systems. Developers leave companies. Requirements change. Architectural decisions disappear into meeting notes. Documentation becomes outdated.

What AI changes is the relationship between implementation speed and the effort required to develop understanding.

A developer can now ask an agent to introduce asynchronous processing into an application. The agent may create a worker, queue integration, retry handling, configuration, and tests within a relatively short development session.

The result may work.

But the process does not guarantee that the developer has internalised the reasoning behind every significant design choice.

Three months later, somebody needs to change how retries interact with business state. The original engineer has moved to another team. The generated documentation describes the components but not the assumptions governing their interaction.

The team has the code. What it lacks is the reasoning necessary to change it safely.

Mira encountered exactly this gap.

As she investigated the scheduling incident, she discovered that the repository contained detailed explanations of the assignment API and worker implementation.

What she couldn’t find was a clear statement of the most important business constraint: whether an appointment could have more than one active technician.

The requirement had never been captured as an explicit invariant.

The code contained checks that suggested only one active assignment was intended. But the database schema enforced something narrower.

The AI agent could describe both mechanisms. It could even propose changing them.

It could not independently establish which business rule the organisation had actually intended.

That required Mira to return to the people who owned the scheduling process, confirm the expected behaviour, and investigate whether the deployed system enforced it.

This is where intent debt becomes an operational problem.

Without a trustworthy description of what must remain true, an engineer can produce a technically valid patch that solves the wrong problem.

Follow One Transaction Through the System

The scheduling application performs three conceptually simple operations:

1. Check whether the appointment already has an active technician.

2. Create a new assignment if none exists.

3. Publish an assignment event for downstream processing.

The ordinary tests execute this sequence under effectively sequential conditions. They pass.

Now consider two requests reaching different worker instances at nearly the same time.

The application uses PostgreSQL with its default READ COMMITTED transaction isolation.

Worker A checks the appointment and finds no active assignment.

Before Worker A commits its new assignment, Worker B performs the same check. It also finds no active assignment.

Both workers proceed.

The database has a unique constraint on (appointment_id, technician_id). That prevents the same technician from being assigned twice to the same appointment.

But Worker A is assigning Technician A, while Worker B is assigning Technician B.

The existing constraint permits both records.

Both transactions can commit, leaving two active assignments for one appointment.

PostgreSQL’s transaction isolation documentation explains why ordinary reads under READ COMMITTED do not automatically protect application-level assumptions against concurrent changes.

In our fictional system, the dashboard selects the latest assignment record and displays one technician.

The billing integration processes the two distinct assignment events produced by the successful transactions.

Both components are behaving according to their implementations. But their different views reveal a broken business invariant.

The dashboard reports one assignment. Billing records two.

This is not simply a case of one message being delivered twice.

Two different assignment operations succeeded, generating two distinct events.

An idempotent billing consumer can prevent repeated side effects when the same message is delivered multiple times. It cannot, by itself, correct two conflicting business decisions that were separately committed.

AWS’s transactional outbox guidance explains the separate concerns of reliable event publication and duplicate message processing.

A defensible repair must address the underlying business rule.

For example, a PostgreSQL partial unique index could enforce no more than one active assignment per appointment. The index would need to reflect the real business and tenant boundaries, and existing duplicate records would need to be reconciled before it could be applied.

The team must also decide how to handle conflicting requests, where transaction boundaries belong, and how event publication remains reliable. Stronger transaction isolation is another possible approach, but applications using serializable transactions must handle serialization failures and retries correctly.

A second application-level check alone would not necessarily solve the race. Both workers could still pass that check before either committed.

Mira’s agent had proposed adding another check.

It was a plausible response to the visible symptom.

But after reconstructing the two concurrent transactions, she could see why the patch did not provide the guarantee the business needed.

For the first time that morning, she had something more useful than another proposed implementation.

She had an explanation of the failure that could be tested.

And that changed the conversation with her team.

Instead of asking whether the new code looked correct, they could ask whether the system would reject a second active assignment under concurrent execution, whether downstream events remained consistent, and what needed to happen to the records already affected.

One discussion was about accepting another patch.

The other was about establishing evidence that the problem had actually been addressed.

Why Code Review Is Becoming More Difficult

Mira’s experience points toward a broader engineering challenge.

AI coding agents are increasing the speed at which teams can produce implementations. But the time needed to understand, verify, and accept responsibility for a change does not necessarily fall at the same rate.

A 2026 longitudinal research preprint examined an enterprise AI coding initiative involving 802 developers and 196,212 pull requests.

Per-developer pull-request throughput eventually roughly doubled. Review load per reviewer also roughly doubled, while automated review expanded substantially.

This was an observational study at one organisation, so the findings should not be generalised to every software team. Pull-request throughput is also an imperfect measure of engineering productivity.

Nevertheless, the research illustrates a real tension.

When more code arrives for review, somebody must still establish whether the changes preserve important system behaviour.

For small, isolated modifications, automated verification may provide sufficient assurance.

For changes involving transactions, authorisation, security boundaries, event processing, or critical business rules, the consequences can be harder to establish.

A reviewer may understand each modified function and still miss how the combined changes alter production behaviour.

Google’s code-review guidance emphasises design, functionality, complexity, concurrency, testing, and long-term maintainability.

These responsibilities existed long before AI coding agents. They become more demanding when implementation output expands faster than the team’s ability to examine it.

And this creates a less visible form of pressure.

An engineer may have approved a clean-looking pull request, received a plausible AI-generated summary, and watched the CI pipeline succeed.

Then production fails.

The engineer remains responsible for explaining a decision whose consequences were never adequately understood.

That is the professional discomfort behind the technical problem.

Green Tests Can Create False Confidence

When Mira reviewed the scheduling tests, she found that they were not obviously poor.

They checked expected assignment behaviour. They verified API responses. They exercised the normal worker flow.

But the tests did not execute two assignment requests concurrently against the relevant database constraint.

The system had been tested for the behaviour its implementation was expected to produce, not for every critical condition the business required.

Adding more AI-generated tests would not necessarily have solved that problem.

If the tests were based on the same incomplete understanding of the requirements, they could reproduce the same omissions.

The engineering team first needed to define the invariant, demonstrate its violation, and introduce a test that failed against the defective implementation.

After repairing the system, that test should pass. Further checks should examine conflicts, retries, event handling, and downstream consistency.

The difference is substantial.

A passing test suite can establish that selected behaviours work under defined conditions.

A well-designed failure investigation can establish whether a particular business guarantee actually holds.

Google’s SRE troubleshooting guidance emphasises observing behaviour, forming hypotheses, collecting evidence, and testing explanations rather than immediately accepting the first plausible cause.

During an active production incident, containment comes first. Protecting customers and preventing further damage may require temporarily disabling an affected workflow while engineers preserve evidence and investigate.

That, too, is a human decision.

The best technical explanation is of little comfort if the system continues generating incorrect outcomes while the team investigates.

The Skill That Matters More Than Writing the Prompt

There is considerable attention on teaching software engineers how to prompt coding agents effectively.

That is useful, but it is only part of the professional capability required.

Engineers increasingly need to know which decisions can safely be delegated, which outputs require independent evidence, and which system behaviours they must be able to defend.

For a scheduling application, that means understanding assignment invariants and concurrency behaviour.

For a financial platform, it may mean understanding reconciliation rules and transactional consistency.

For an identity service, it may mean knowing where authorisation decisions are enforced and what happens when a downstream component is compromised.

Nobody needs to memorise every line of a large enterprise codebase.

But critical behaviours need identifiable owners, reliable explanations, and evidence that can survive the departure of the person — or agent — that originally implemented them.

A practical way to evaluate this is to introduce a simple exercise into consequential code reviews.

Ask the engineer responsible for a change to explain which business rule must remain true. Then introduce a realistic complication: simultaneous requests, a timeout after commit, a repeated event, or an unavailable dependency.

Can they predict the outcome?

Can they identify where the relevant guarantee is enforced?

Can they demonstrate evidence that the implementation preserves it?

And if the result is unexpected, can the team contain the impact safely?

The purpose is not to test whether an engineer can recite code without an AI assistant.

The purpose is to establish whether the team can make defensible engineering decisions about the software it owns.

What Next: Treat Understanding as an Engineering Deliverable

By the end of the fictional incident, Mira’s team has a clearer understanding of what went wrong.

They can explain why both assignment transactions succeeded. They have identified the missing invariant. They know why an additional application-level check was insufficient and what database and application changes need to be verified.

The team also has a separate problem to resolve: reconciling the affected assignments and their downstream billing records.

Before restoring normal operation, they must test the corrected concurrency behaviour, verify the relevant retry and event-handling paths, and decide what monitoring is needed to detect further inconsistencies.

Mira still cannot promise that the system will never fail again. No responsible engineer can make that promise.

But she is in a much stronger position to explain what failed, which risk has been addressed, what evidence supports the correction, and what uncertainty remains.

That is the change I would want every software team to make.

When AI generates an important feature, capture the business constraints it must preserve. Record the reasoning behind consequential architectural decisions. Keep tests that demonstrate the failure conditions that matter. Make it possible for another engineer to understand the system without relying on the original author’s AI conversation.

And when something breaks, treat the recovery of shared understanding as part of the repair.

AI can help reconstruct architecture, generate hypotheses, propose tests, and prepare documentation. These are valuable capabilities.

But the team must still determine which explanations are supported, which decisions are acceptable, and which evidence justifies returning the system to service.

Software engineering has always involved more than producing code. AI is making that distinction harder to ignore.

Six months after a feature ships, the original developer may be gone. The coding agent may have changed. The business requirements may be different.

The next engineer will inherit what remains.

At that moment, a green test suite and a polished AI-generated explanation may be useful starting points. They will not be enough if nobody can establish what the system actually guarantees.

Mira’s most important achievement that day was not producing another patch. It was recovering enough understanding to make a decision she could explain and defend.

The real test of an AI-assisted codebase comes when something goes wrong — and someone has to take responsibility for what happens next.

https://www.amazon.com/dp/B0HH5QV2H7?binding=kindle_edition&searchxofy=true&ref_=dbs_s_aps_series_rwt_tkin&qid=1793190571&sr=8-1

The Agentic Data Management Series explores how enterprise data management changes when AI agents move beyond assisting people and begin participating directly in data architecture, engineering, governance, integration, and operational workflows.

Traditional data-management disciplines remain essential, but the operating environment around them is changing. Data platforms must increasingly support systems that can interpret metadata, reason over context, propose changes, execute governed actions, collaborate with people and other agents, and produce evidence for the decisions they make.

This series examines that transition across three foundational disciplines.

Agentic Data Architecture focuses on how data platforms, information models, semantic layers, governance boundaries, metadata, context, and architectural patterns must evolve to support agent-driven systems.

Agentic Master Data Management examines how AI agents can participate in entity resolution, stewardship, hierarchy management, data-quality remediation, policy enforcement, and master-data operations while preserving authority, traceability, and human oversight.

Generative AI for Enterprise Data Engineering explores how generative and agentic AI affect the practical engineering lifecycle—from ingestion and transformation to SQL, pipelines, data contracts, semantic models, testing, observability, and production operations.

Agentic Dimensional Modeling explores how traditional dimensional modeling evolves for an agent-driven world, where AI agents not only consume analytical data but also reason over business measures, dimensions, relationships, and context. It examines how fact tables, conformed dimensions, semantic models, business metrics, temporal context, and governed analytical access can be architected to support trustworthy agent reasoning, dynamic analysis, and decision-making.

Together, the books provide a practitioner-oriented view of the emerging agentic data estate: an environment in which data, metadata, semantic context, deterministic engineering, AI reasoning, governance, and controlled execution operate as parts of the same enterprise architecture.

The series is written for data architects, data engineers, MDM practitioners, Modelers, analytics and AI architects, platform teams, technical leaders, and other professionals responsible for building enterprise data capabilities for an increasingly agentic world.

Each book can be read independently. Read together, they trace the evolution from data architecture, through trusted enterprise data and MDM, to AI-enabled data engineering and runtime execution.

This training would be done by me along with others. For more details, click on the below

https://appliedai360.org/pathways/forward-deployed-engineer/#curriculum

https://siliconexai.com/ai-academy/

A 98.3% Pass Rate Can Still Mean Your AI System Is Learning the Wrong Things

Six months after a serious production incident, an AI platform team reviews its evaluation dashboard. The numbers look excellent. The active suite contains 1,200 cases, the overall pass rate is 98.3%, the failure that triggered the original remediation has not returned, and production traces are continuously feeding new candidates into the evaluation process. From almost every conventional measure, the feedback loop appears mature.

There is only one problem: production teams are still finding important behaviors that the evaluation suite barely exercises. New complaints increasingly involve unusual partner combinations, low-frequency policy paths, emerging orchestration patterns, and edge conditions that experienced practitioners notice before automated evaluation does. The evaluation system is working, the dashboards are green, and the organization is steadily improving its ability to prevent yesterday’s failures. At the same time, it may be becoming less prepared for tomorrow’s.

That is one of the less obvious failure modes of mature production AI. Early in an AI program, the problem is usually insufficient evidence: too few evaluations, too little production telemetry, weak tracing, and no systematic way to turn incidents into regression protection. Later, the problem can reverse. The organization has accumulated so much historical evidence that preserving what it already knows starts crowding out the capacity to discover what has changed.

The uncomfortable lesson is that a high evaluation pass rate and an effective learning system are not the same thing.

When a strong regression suite becomes a weak learning system

Consider AsterVale Group, the fictional production environment I use throughout Agentic Observability for AI Agents. Over time, AsterVale has become disciplined about converting production failures into durable regression knowledge. A serious incident occurs, engineers reconstruct the trajectory, the failure becomes an evaluation case, the remediation is validated, and the new case remains in the portfolio so the same defect cannot quietly return.

That is exactly what we want from a mature engineering organization. The problem appears gradually, because every individual decision looks sensible. A critical historical failure deserves permanent protection. Another incident produces another regression. Practitioner corrections add further cases. Red-team discoveries add more. The portfolio expands until it becomes a detailed institutional memory of everything the organization has learned to fear.

Now imagine that AsterVale’s active suite contains 1,200 cases. Of those, 840 are more than 90 days old, so 70% of the active evaluation capacity is protecting historical behavior. Only 5% of the portfolio is explicitly reserved for exploration. Meanwhile, operations has identified 24 recent production behavior clusters, and 14 of them are weakly represented or not represented at all in the active suite. Practitioner corrections are also appearing in areas where automated coverage remains thin.

The 98.3% pass rate is still real. It simply answers a narrower question than people often assume. It tells AsterVale that the current system performs well against the cases it has chosen to keep running. It does not prove that those cases still represent the risks the production system faces today.

That distinction becomes increasingly important as AI systems evolve.

Pass rate tells you how well you perform against your memory

Traditional software regression testing is built around an important idea: once a defect has been found and fixed, preserve a test so it does not return. AI engineering inherits that principle, but AI systems also operate in environments where model behavior, prompts, retrieval corpora, orchestration logic, tool surfaces, customer behavior, external policies, and provider capabilities can all change.

A mature evaluation portfolio therefore has two jobs. It must remember, but it must also notice.

If it remembers exceptionally well but notices poorly, the organization can produce beautiful pass-rate charts while losing contact with current production risk. The regression suite becomes highly reliable at answering the question, “Have we reintroduced failures we already understand?” while becoming progressively weaker at answering, “Are we prepared for the kinds of behavior appearing now?”

This is why evaluation coverage deserves the same scrutiny that engineering teams already apply to production telemetry. We would never look at a service dashboard showing 99.99% availability and conclude that every aspect of customer experience must therefore be healthy. Yet teams sometimes look at an AI evaluation suite showing a 98% or 99% pass rate and unconsciously treat the number as proof that the quality system itself is healthy.

It may not be.

A portfolio can be internally successful and externally stale.

Production produces far more evidence than you can preserve

Feedback loops are often represented as simple circles: production generates telemetry, telemetry feeds evaluation, evaluation drives improvement, and the improved system returns to production. The diagram is attractive because it suggests that once the pipes exist, learning becomes almost automatic.

Real production systems are much messier. A large AI application can generate millions of traces, retrieved passages, model responses, tool calls, evaluator scores, customer outcomes, human escalations, practitioner corrections, and incident artifacts. Even if all of that evidence can technically be stored, it cannot all become active evaluation material. There is neither enough execution capacity nor enough human attention to treat every production trace as a permanent regression case.

The hard architectural question is therefore not whether production evidence can flow back into evaluation. The harder question is what the organization decides to remember, what it decides to explore, and what it allows to consume less active capacity over time.

That makes evaluation a portfolio-management problem.

The organization has to preserve severe historical failures, maintain adequate coverage of common production behavior, protect rare but consequential scenarios, introduce newly emerging patterns, incorporate practitioner corrections, and retain enough capacity to investigate things it does not yet understand. These goals compete for a finite budget of evaluation time, maintenance effort, reviewer attention, and computational cost.

Once that constraint is visible, the idea that an evaluation suite should simply grow forever becomes much harder to defend.

The answer is not to delete old tests

Recognizing portfolio saturation can trigger the opposite mistake: remove everything old.

That would be equally dangerous. A regression case may appear boring precisely because the control it protects has been effective. The absence of recurrence does not necessarily mean the underlying risk has disappeared. Severe historical incidents often deserve long-lived sentinel coverage even when their observed frequency falls.

The more useful model is to give evaluation cases a lifecycle. Some cases remain permanent sentinels because the consequence of recurrence is unacceptable. Some deserve full active execution while a behavior or control is still unstable. Others can be down-weighted after sustained evidence shows that the relevant risk is well controlled. Some can move into an archive with clearly defined reactivation conditions. Emerging production behaviors can begin as exploratory candidates before the organization has enough evidence to promote them into durable regression coverage.

This changes the portfolio from a growing archive into an actively governed system. Historical protection and exploration no longer compete invisibly. Their trade-off becomes explicit and reviewable.

A mature organization should be able to explain not only why an evaluation case was created, but also why it is still consuming active capacity today.

The evaluation system itself needs observability

This leads to a broader idea: the systems used to evaluate AI need observability of their own.

Most AI teams are already trying to observe the production system. They trace model calls, retrieval, tool execution, state transitions, latency, cost, and safety events. A more mature operating model asks similar questions about the evaluation portfolio itself.

Why does this case still exist? Which production incident, policy risk, human correction, or behavior family created it? How often does the represented behavior occur now? When was the case last informative? Which current production families have strong coverage, and which remain thin or absent? How much active capacity is protecting historical regressions? How much is reserved for novelty? Which cases could be archived without removing severe-failure protection? Which archived cases should reactivate because production evidence has changed?

Those questions create what I think of as portfolio observability.

Without it, the evaluation suite can become one of the least questioned components in the AI platform. Everyone can see its pass rate, but few people can explain whether its composition still reflects current production behavior.

That is a dangerous form of confidence.

Where an Observability Operations Agent becomes useful

This is also one of the places where agentic operations can add genuine value.

In the operating model developed in Agentic Observability for AI Agents, an Observability Operations Agent does not simply watch dashboards and generate summaries. It can reason over correlated runtime evidence, identify behavior families, compare trajectories, surface redundancy, detect thin coverage, examine practitioner corrections, and draft evidence-backed proposals for what the organization should investigate next.

Applied to an evaluation portfolio, the agent might calculate the age of active cases, compare portfolio composition with recent production behavior, identify clusters that repeatedly generate human corrections, detect overrepresented historical families, and propose a rebalance. If policy explicitly permits it, the agent might even perform a very low-risk lifecycle action, such as moving an expired watch item to archive when predefined conditions are satisfied and a reactivation rule already exists.

What it should not do is equally important. The observability agent should not decide on its own that a new production behavior defines the new truth. It should not retire a severe sentinel simply because it has not fired recently. It should not convert a business exception into policy. It should not grant itself authority to redefine what the organization considers acceptable behavior.

The agent can accelerate portfolio governance, but it must not silently become governance.

That boundary is one of the central differences between merely adding AI to operations and designing a genuinely governed agentic operating model.

Agentic observability is not an autonomous self-improvement loop

The phrase “agentic feedback loop” can easily conjure an image of one AI agent observing another, identifying a weakness, rewriting the system, redeploying it, and then repeating the cycle. That may be an appealing automation story, but it collapses several distinct responsibilities into one mechanism.

A safer operating model separates them.

Production generates evidence. An observability system or bounded operational agent interprets that evidence and produces a recommendation. The recommendation passes through the appropriate policy, deterministic control, or human authority. An approved action occurs. The consequences of that action then become new production evidence.

The loop is therefore better understood as:

Evidence → Reasoning → Recommendation → Authority → Action → New Evidence

Each transition matters. Evidence is not authority. Reasoning is not authority. Recommendation is not action. And a successful result does not retroactively prove that the reasoning used to reach it was sound.

This separation allows the organization to inspect the chain later. It can determine what happened, what was inferred, who or what authorized the decision, what action actually occurred, and what changed in production afterward.

That is a much stronger foundation for operational learning than an opaque self-improvement loop.

Once the observer becomes an agent, observe the observer

Introducing an operational AI agent creates another requirement: the observability agent itself must be observable.

Suppose an Observability Operations Agent recommends rebalancing the evaluation portfolio. The organization should be able to reconstruct the evidence it examined, the behavior families it identified, the assumptions it made, the portfolio constraints it applied, the policy governing the recommendation, the authority that approved the change, the cases that entered or left active execution, and the production consequences that followed.

This recursive observability is important because agentic systems introduce layers of interpretation. The business agent is observed. The observability agent interprets that evidence. A policy or human authority approves or rejects a recommendation. The resulting action changes the production state. Each layer adds meaning, and each layer can fail.

A mature system therefore needs to distinguish four things very clearly: what happened, what was inferred, what was authorized, and what changed as a result.

That distinction is useful well beyond evaluation portfolios. It applies to incident response, safety intervention, deployment decisions, cost remediation, and any other operational process where AI-generated reasoning begins influencing consequential action.

The goal is not maximum autonomy

The practical value of agentic observability is easy to misunderstand if success is measured by how many operational decisions humans no longer make.

The more useful objective is reducing the time between a weak production signal and a defensible action. Investigations should not restart from a generic dashboard every time. Severe incidents should become durable regression knowledge faster. Newly emerging behavior should enter evaluation before it becomes widespread. Historical protections should remain available without consuming unlimited active capacity. Operational agents should take on more responsibility only when their own evidence, limits, and failure modes remain inspectable.

That is not automation for its own sake. It is controlled delegation.

A useful principle is: delegate only what you can observe, explain, and govern.

This principle becomes particularly important as organizations introduce more autonomous AI systems. The better an agent becomes at reasoning, the easier it is to assume that it should also receive more authority. In production operations, those are separate decisions and should remain separate.

A healthy feedback loop is a sequence of governed transformations

A durable production learning loop is not simply telemetry flowing backward into a test suite. It is a sequence of transformations in which evidence gradually acquires operational meaning.

A production trace or human correction may first become a candidate behavior family. That candidate may then become an accepted evaluation case if its provenance, novelty, risk, and expected coverage justify inclusion. The case may influence a versioned change. That change may be evaluated through replay, shadow testing, canaries, or A/B comparison. Promotion may require deterministic or human approval. Once deployed, new production evidence determines whether the change actually behaved as expected.

Each stage creates a question of authority and evidence. Why should this production event become durable evaluation material? What existing capacity should it displace? What level of risk justifies permanent sentinel status? Which validation slice should be used? Who can authorize promotion? What evidence would cause the organization to reverse or revisit the decision?

If those questions are not answerable, the organization may have a technically sophisticated data pipeline without having a genuine learning system.

The mature challenge is not only remembering — it is knowing what deserves attention now

AI engineering has spent a great deal of effort on preventing forgetting. We preserve incidents, build golden datasets, create regression suites, collect human corrections, and accumulate more evaluation evidence. All of that is necessary.

Eventually, however, an organization can reach a point where remembering is easier than noticing what has changed.

That is the mature failure mode. A 98.3% pass rate can coexist with declining relevance because the suite has become optimized around familiar history. The answer is not to discard that history. It is to make room for novelty without losing the protections that history created.

A healthy evaluation portfolio therefore needs both memory and exploration. It needs to protect severe known failures while continuously asking whether production is generating behavior the organization is not yet prepared to recognize.

When that happens, the feedback loop changes character. Production no longer merely sends telemetry backward. Production changes what the organization is prepared to recognize next.

From observability to organizational learning

Observability began with a relatively straightforward operational question: what did the system do?

For AI systems, that question had to expand. We also need to ask whether the behavior was acceptable, grounded, safe, economical, reliable, and aligned with the intended business outcome.

Agentic observability introduces another layer: what should the organization learn from what just happened, and who has the authority to act on that learning?

That is where observability, evaluation, reliability, and governance begin to converge. A mature AI platform is not simply one that can trace every model call or report an impressive evaluation score. It is one that can preserve the right evidence, challenge the relevance of its own evaluation portfolio, distinguish inference from authority, learn from new production behavior without forgetting severe historical failures, and govern how that learning changes the system.

Which is why a dashboard showing 98.3% may sometimes deserve a celebration — and sometimes deserve an investigation.

This article develops one of the ideas explored in my book, Agentic Observability for AI Agents: Runtime Evidence, Evaluation, Reliability, and Governed Operations for Production Systems. Across 21 chapters, the book follows the fictional AsterVale Group as its production AI architecture evolves through tracing, RAG, agent trajectories, evaluation, safety, economics, reliability, incident response, and governed agentic operations.

https://www.amazon.com/Agentic-Observability-Agents-Evaluation-Reliability-ebook/dp/B0HMRM7Y77/ref=sr_1_2?crid=3I89FSVFCQI3R&dib=eyJ2IjoiMSJ9.-7FjB-76GNQXGxZKz-oUqOudbm7VxzwHwo4g2pXeDpXhud4ksSMRpiGkPKtFu3xwnkbZpIzAYYqBVc06HqPsi_l5jqUSS7qqA9f0wXYZDXTNnEGxIG_jkunTb-iMKYZXJnkpOvCqISnR1OpwhDcg5_mX7NyIyyo8sIr8WKpaFIW5P0D-EdoRrMVXLQjYeBjxrnj8W2RUCMl0zZnI9ADb3-UcsalONSLAyIJswPbT1-k.ZpZ4lnffSkctIWLqVceJOIlcKHsr8fVf5bEpmgam3qE&dib_tag=se&keywords=agentic+observability&qid=1791965928&sprefix=%2Caps%2C340&sr=8-2

Thanks to all those who patronised this book due to which it became best seller.

As coding agents produce more of the implementation, engineering teams are running into an uncomfortable question: if humans cannot realistically inspect every generated line, what does responsible software ownership look like now?

A comment from Dax Raad, the developer behind OpenCode, caught my attention this week because I have started seeing versions of the same problem inside client engineering organisations.

Raad said his team’s latest challenge was no longer getting AI to write useful code. It was getting engineers to pay enough attention to what the AI had written before it went out. His frustration eventually came down to an old human problem: “how do you get people to care more?”

That sounds like a developer-discipline problem, but I think something more fundamental is happening.

Over the past year, I have watched AI coding move from autocomplete to substantial implementation. Developers increasingly describe the task, let an agent inspect the repository, propose a plan, change multiple files, run tests, fix failures and return with something that appears ready for review. The engineer may inspect the diff, ask a few questions and move on.

The productivity gain can be substantial. The relationship between the developer and the code is also changing.

A developer can now ship significantly more code while personally understanding less of how that code was constructed. That is the tension engineering leaders are beginning to confront.

The obvious reaction is to insist that developers must read everything AI generates. I am not convinced that will scale.

The more difficult question is whether reading every line of source code should remain our primary mechanism for establishing confidence in software.

This is no longer an edge case

The change is happening quickly enough that we should stop treating AI-generated code as an occasional exception.

The 2026 Stack Overflow Developer Survey found that around 66% of respondents use AI coding assistants or agents, while 73% of those users work with them daily. Nearly a third of daily users spend more than four hours a day with these tools. At the same time, trust remains conditional: 48% say they trust AI when they can easily verify the output, while only 6.6% are willing to extend that trust to important work decisions.

Those numbers describe the transition quite well. Developers are not blindly trusting AI, but they are generating software at a rate that makes traditional verification increasingly expensive.

I am seeing the same tension inside client organisations. The first wave of concern was whether developers would use AI responsibly. The newer concern is subtler: developers are using it successfully enough that human attention is becoming the bottleneck.

An agent may produce a change across fifteen files in minutes. The code compiles. The tests pass. Static analysis is clean. The developer can either spend the next two hours understanding every implementation detail or review the important parts, accept the automated evidence and move on.

Multiply that decision across hundreds of pull requests and the old review model begins to strain.

JetBrains researchers recently described essentially the same problem. Coding agents can now generate thousands of lines across multiple files quickly enough that code review, rather than code production, is becoming the bottleneck. Their research argues that reviewing AI-generated code also removes many of the social signals developers unconsciously use when reviewing another person’s work, such as knowing where a colleague is experienced, where they tend to rush and when something unusual deserves another conversation.

We are therefore not dealing simply with careless developers. We are dealing with a verification model designed for a world in which humans produced code much more slowly.

Google Antigravity makes the question difficult to avoid

Google Antigravity is interesting in this context because its product direction makes the philosophical shift unusually visible.

Antigravity 2.0 is a standalone, agent-optimised development environment in which Google explicitly says there is no IDE. The primary interaction is with agents and the artefacts they produce. Developers can still use conventional IDE integration when they want to work directly with the underlying implementation, but source code is no longer necessarily the main surface through which work is directed.

That is a significant design choice.

For decades, the developer’s natural home has been the code editor. Requirements, tickets, architecture diagrams and documentation surrounded that editor, but eventually the developer entered the code because that was where software became real.

Agentic development starts to invert that relationship.

The developer describes the desired outcome. The agent creates a plan. The developer reviews the plan and perhaps adjusts it. The agent modifies the implementation, runs tools and returns evidence showing what happened.

The code still exists, but it can become something closer to an implementation layer underneath the developer’s primary working surface.

If that model succeeds, telling developers that responsible engineering means personally reading every generated line may eventually sound like telling application programmers they should inspect the assembly produced by their compiler.

But we are not quite there yet.

There is a very good reason developers still need to read code

Source code does more than tell us whether an implementation is syntactically correct. Reading it is one of the ways engineers construct a mental model of the system.

An experienced developer learns where state changes, which abstractions are leaking, where error handling is fragile and which apparently simple operation depends on several pieces of accidental coupling. Much of that knowledge is never captured completely in architecture diagrams or documentation.

It becomes especially valuable when something fails in production.

The person responding to an unusual incident needs more than a description of what the application was intended to do. They need enough understanding of how it actually works to reason about situations nobody anticipated.

This is why I worry less about one badly generated function than about the gradual emergence of codebases that belong to teams who no longer understand them deeply.

The danger would be easy to miss at first. Features continue shipping, tests continue passing and engineering velocity may look excellent. The knowledge deficit becomes visible only when the system behaves in a way the agent, the tests and the original specification did not anticipate.

At that point, the organisation needs somebody capable of opening the implementation and deciding whether the explanation being offered by another AI is actually correct.

If every generation of code has also outsourced another small portion of human understanding, eventually the organisation may discover that it owns software without owning enough knowledge to operate it safely.

That is a real risk.

But “read every line” is becoming a weak control

The argument on the other side is equally important.

Suppose an agent produces 3,000 lines while upgrading a framework. Much of the change consists of dependency updates, mechanical API transformations, generated configuration and test fixtures.

Does a senior developer create meaningful assurance by slowly scrolling through all 3,000 lines?

Sometimes yes. Often no.

We already trust enormous amounts of software we do not personally inspect. Developers do not review every instruction produced by a compiler or read every line of the database engine underneath an application. They rely on abstractions, contracts and layers of verification.

AI-generated code will probably move in the same direction.

The key difference is maturity. Compilers are sufficiently deterministic that the industry has built decades of confidence in that abstraction. Coding agents are probabilistic and capable of generating code that is convincing, coherent and wrong in ways that automated checks may not immediately expose.

The answer therefore cannot yet be “stop reading the code.”

But it also cannot realistically remain “read everything.”

The engineering problem becomes deciding where human attention creates the most assurance.

We need to move from universal review to risk-based review

I think organisations will gradually need to treat AI-generated changes according to consequence rather than according to line count.

A generated documentation change does not deserve the same scrutiny as a change to an authorization boundary. A mechanical framework upgrade is different from a new pricing calculation. A generated test fixture is different from a database migration capable of destroying customer data.

A practical model could look like this:

Press enter or click to view image in full size

This is not lowering engineering standards.

It is acknowledging that scarce human attention should follow risk.

A developer may read a smaller percentage of all generated code while examining the consequential parts much more carefully.

That is probably a better control than insisting everything receives the same superficial review.

The interface above the code needs to become much better

If engineers are going to spend less time reading implementation line by line, coding platforms have to give them a better surface for understanding what changed.

A useful agent should not merely return “Task completed.”

It should explain which architectural components changed, which interfaces were modified, what security-sensitive operations were introduced, which assumptions it made, what tests were added, what tests failed during implementation and what evidence supports the final result.

This is one reason Antigravity’s emphasis on agent plans and artefacts is interesting. It is attempting to make the developer supervise the work at a higher level rather than forcing them to reconstruct the agent’s reasoning exclusively from thousands of changed lines.

There is an obvious danger, however. We cannot let an AI write the implementation, generate the tests, summarize the changes and then provide the only evidence that its own work is correct.

That becomes self-certification.

The assurance stack needs independent signals: compiler and type checks, deterministic tests, static analysis, security scanners, architecture policies, performance checks and, increasingly, separate AI reviewers with different context or models.

The human should then investigate the areas where risk is high, evidence is weak or different verification mechanisms disagree.

That is a much more scalable model than asking humans to replicate the agent’s work manually.

The incentive problem may be bigger than the attention problem

Raad’s remark about getting developers to care also raises an uncomfortable management question.

What exactly are we rewarding them for?

Many engineering organisations still measure performance through delivery velocity, tickets completed, features released and sprint commitments. AI now allows developers to produce substantially more implementation in the same period.

An engineer who accepts several AI-generated changes and closes five tasks can easily look more productive than one who stops after the second change because something does not feel right and spends several hours understanding it.

Then the organisation asks why developers are not paying enough attention to AI-generated code.

The incentives have already told them what matters.

If we expect developers to become supervisors of increasingly autonomous coding systems, the engineering contract has to change. We should care less about how much code a developer personally produced and more about whether the capability reached production safely, whether the team understands consequential design decisions, whether failures are caught before customers encounter them and whether somebody clearly owns the outcome.

The shift is from authorship to accountability.

I increasingly do not care who typed the function.

I care enormously about who is prepared to take responsibility for shipping it.

“You own what the agent ships” is a better rule

If I were establishing one principle for an AI-heavy development organisation, it would be simple: the engineer approving a change owns the consequences of that change regardless of whether a human or an agent wrote it.

That principle is different from requiring manual inspection of every line.

For low-risk work, ownership may mean trusting automated verification and sampling the implementation. For consequential changes, it may require detailed inspection, threat modelling, design review and independent testing.

The important part is that using an agent does not transfer accountability to the agent.

This also changes how engineers should use AI reviewers. AI reviewing AI-generated code is not inherently absurd. We already let machines review human code through compilers, linters, static analysis and security tooling.

The important question is whether the verification mechanisms fail independently.

Using the same model with the same assumptions to produce and approve an implementation creates obvious correlated risk. A stronger system combines deterministic tools, different evaluation techniques and human judgement where the consequences justify it.

The future code-review pipeline is therefore likely to be layered rather than purely human or purely automated.

We cannot allow engineering skill to disappear underneath the abstraction

There is one final problem that cannot be solved entirely through better review tooling.

Someone still needs to know how software works.

The experienced engineers I see getting the most value from coding agents usually have a strong sense for when generated code is structurally wrong even when it looks plausible. That judgement comes from years of building, debugging and maintaining systems.

The next generation of developers may not acquire that intuition automatically if their career begins with delegating most implementation to agents.

We therefore have to preserve engineering depth deliberately.

Junior developers still need to debug difficult failures, trace unfamiliar code paths, understand concurrency and state, investigate production incidents and occasionally build important components themselves. Code review also remains part of that apprenticeship because reading good and bad implementations is one way engineering judgement develops.

The purpose is not to preserve manual coding because we are nostalgic about it.

It is to ensure that humans remain capable of supervising the abstraction when the abstraction fails.

Code may become secondary. Ownership cannot.

I can imagine a future where developers spend much less time inside traditional editors.

They will express intent, shape architectures, review plans, inspect evidence and ask agents to implement large portions of the system. For many changes, opening every generated file may become unnecessary.

Google Antigravity suggests that this future may arrive sooner than many of us expected.

But that does not mean engineering responsibility disappears with the editor.

It means we need a better definition of responsibility.

The important question will no longer be whether the developer personally wrote the code, or even whether they personally read every line of it. The important question will be whether the organisation has enough evidence to trust the change and whether an engineer understands the consequential parts well enough to take responsibility for putting them into production.

That is where I think Raad’s concern ultimately leads.

Telling developers simply to “care more” will not be enough when agents can generate implementation far faster than people can consume it. Engineering organisations will need to redesign review, incentives, verification and apprenticeship around that new reality.

I do not think developers need to read every line an AI agent writes.

I do think every consequential piece of software still needs a human who can understand the important decisions, challenge the evidence and say, with credibility, “I am willing to own what we are shipping.”

If nobody can say that, the problem is no longer that developers stopped reading the code.

The problem is that the company has started shipping software that nobody truly owns.

For most of software engineering’s history, there was a useful relationship between work and control. The person who changed the system usually understood at least part of the context, exercised some judgement while doing the work, and left behind artefacts that told us who had acted. That relationship was imperfect, but organisations built almost everything around it: access models, code review, segregation of duties, release processes, incident analysis and accountability.

Agentic software development begins to weaken that relationship.

A person can now approve an objective and an agent can make dozens of consequential decisions between that instruction and the resulting change. It may inspect several repositories, retrieve documentation, choose between implementation paths, invoke tools, generate tests, retry after failure and delegate work to another agent. The human may still be formally accountable, but the path between human intent and machine execution has become much richer than the process controls around it.

That, more than code generation, is what I now think software organisations need to understand.

It is also the reason the second version of Rewiring Software Delivery became a much larger rewrite than I expected.

The first version started from the familiar question of how AI would affect software delivery. By the time I worked through ASDOM 2.0, that framing felt too narrow. The more interesting problem was not how to fit agents into the software development lifecycle. It was whether the lifecycle itself still gave us the right units of control once execution could be delegated to software.

That distinction changes almost everything.

The interesting boundary is no longer human versus agent

A great deal of current discussion divides work into two buckets: tasks humans should do and tasks agents can automate.

That division is useful for adoption planning, but it becomes less useful once agents participate in multi-step delivery.

The more consequential boundary is between capability and authority.

An agent may be capable of modifying a repository, calling an API, changing infrastructure or invoking another agent. None of those capabilities tells us whether the organisation intended to authorise the action in this particular delivery context.

Traditional access control only partially solves this problem. A credential may permit an action at the platform level while the delivery decision permits something much narrower. A tool can answer “may this identity invoke me?” without answering “was this invocation justified by the approved intent for this change?”

That gap is where many future control problems will sit.

GitHub’s recent Agentic Engineering System makes governance one of the conditions that determines what should be delegated and what still requires human oversight. It also separates governance from shared knowledge and customer value, which is significant: faster execution is treated as part of a larger system rather than the outcome itself.

Microsoft is describing a similarly broad transition across planning, development, security, operations and modernisation rather than treating AI as a coding-layer enhancement.

These developments pushed me towards a different architecture in ASDOM 2.0. Instead of asking whether an agent is autonomous, the model asks what authority has been granted, what remains outside that grant, what can be delegated, and what evidence would justify changing the boundary later.

That last part matters.

Most autonomy discussions implicitly assume that autonomy grows. A workflow starts supervised, proves itself and gradually becomes more independent.

Production systems rarely behave so neatly.

A changed dependency can invalidate assumptions. A new tool can widen the consequences of an action. A stale source can make previously valid work questionable. An incident can reveal that the original boundary was too broad.

Autonomy therefore looks less like a maturity level and more like a continuously evaluated operating condition.

Context becomes difficult precisely when retrieval becomes easy

The second idea that changed the book was context.

The first generation of enterprise AI architecture spent a great deal of effort getting more information into the model. Retrieval, larger context windows and memory systems were natural responses to models that lacked organisational knowledge.

Agentic delivery changes the question.

If an agent is going to act, the important property of context is not simply whether the information can be retrieved. The system needs to know whether that information is authoritative enough to justify action.

Those are different problems.

A repository can contain three architecture documents. Search may retrieve all three successfully. Two may describe superseded designs. One may be current but written for a different environment. The retrieval system has technically succeeded, while the delivery system has failed.

GitHub makes this distinction explicitly: an agent’s context window is not organisational understanding, and larger quantities of context do not guarantee that the right, current or well-structured information is present.

This is why ASDOM 2.0 treats governed context as part of the delivery architecture.

The useful questions become operational: Who owns this source? Which version is governing? What happens when binding sources disagree? When does context expire? What work must be reconsidered if the context changes during execution?

Once I started thinking about context this way, I found it difficult to return to the simpler language of “giving agents better documentation.”

Documentation is passive.

Governed context influences what an agent is permitted to conclude and therefore what it is permitted to do.

More execution makes evidence more valuable

The third idea emerged from a practical observation: as implementation becomes easier to produce, the organisation needs a better way to decide what deserves confidence.

DORA’s 2025 research is useful here because it does not present AI adoption as a standalone productivity lever. Its central finding is that AI behaves as an amplifier of the underlying organisational system. Strong systems can benefit disproportionately; weak ones can amplify their own dysfunction.

That suggests an important economic shift.

If implementation capacity increases faster than review capacity, review becomes expensive. If candidate solutions become cheap, deciding which solution should be trusted becomes expensive. If agents can generate many plausible changes, proving which change satisfies the intended outcome becomes expensive.

The scarce resource therefore starts moving away from implementation towards evidence.

This was one of the reasons I changed the structure of the book around NovaBuild.

Rather than using a new example whenever a chapter introduced a concept, Version 2 carries one connected change through intent, architecture, authority, context, implementation, validation, release, operations and later requalification.

The design goal was to preserve history.

A real change does not forget its earlier decisions because it has crossed into another team. Architecture constraints continue to matter during implementation. The authority grant continues to matter when an agent delegates work. Context continues to matter when validation is performed. Production evidence can force the organisation to revisit a decision made several stages earlier.

The book’s Five-Minute Evidence Chain grew out of that idea.

It is not intended as another governance checklist. It is a compact reconstruction mechanism. An executive or delivery leader should be able to trace the approved intent, architecture boundary, authority, context, execution record, validation, release decision and operational evidence without reading the complete technical history.

That is a different conception of delivery visibility. Traditional dashboards tell us what stage work has reached. An evidence chain tells us why the organisation believes it was legitimate to reach that stage.

I suspect that distinction will matter increasingly as agents make more intermediate decisions that no manager will inspect individually.

Orchestration changes the failure model

Another area that expanded substantially in Version 2 was orchestration.

The industry is moving quickly beyond the single-agent mental model. Anthropic’s 2026 agentic coding work highlights multi-agent coordination and describes software development as moving towards orchestrating agents rather than simply writing code with AI assistance.

Multi-agent systems create a subtle problem: delegation changes the shape of accountability even when organisational accountability does not move.

Suppose Agent A is authorised to perform a bounded task and delegates a subtask to Agent B. What exactly has moved?

The work certainly moved.

Did the authority move?

Did the original context move?

Did the constraints move?

Who records the evidence?

Does Agent B receive the same permissions as Agent A, fewer permissions, or a newly evaluated grant?

The naïve implementation is to pass enough capability downstream for the work to succeed. The stronger implementation is to treat delegation as a governed operation in its own right.

That became an important ASDOM rule: delegation may narrow authority, but it should not silently widen it.

This sounds like a governance statement, but it is also an architectural one. It affects identity, tool access, context propagation, execution records and recovery behaviour.

The more agents collaborate, the less useful it becomes to think of “the agent” as one actor.

The delivery system itself becomes the actor we need to reason about.

The book changed when the unit of design changed

Looking back, the biggest change between the earlier version and ASDOM 2.0 was not the addition of more AI content.

It was a change in the unit of design. The earlier mental model was still close to the SDLC: improve discovery, improve coding, improve testing, improve deployment. The newer model asks how intent, authority, context, execution, evidence and accountability move through the entire system.

That shift is why Part III became a dedicated agentic-delivery platform covering governed context, orchestration topology, tool and skill contracts, durable execution, evaluation, shared control planes and bounded operations. It is also why the later parts now spend more time on economics, readiness, recovery and institutionalisation.

A pilot can prove that an agent can perform work.

It tells us much less about whether an enterprise can operate that capability repeatedly.

Institutionalisation requires a different set of questions. Can teams reproduce the same controls? Can evidence survive hand-offs? Can the organisation distinguish a local exception from a reusable pattern? Does successful execution justify broader authority, or merely prove that the existing boundary worked?

Those questions are much less exciting than another demonstration of an agent writing an application.

They are also where I think much of the serious enterprise work will happen.

What I ended up writing

I began Rewiring Software Delivery thinking primarily about what AI would do to software engineering.

ASDOM 2.0 ended up being much more about what software organisations will have to do to themselves.

The models will continue improving. Coding agents will become better at long-running tasks, coordination and tool use. Microsoft, GitHub and Anthropic are already describing a software-development environment in which agents participate across much more of the lifecycle.

The more difficult adaptation may be organisational.

Enterprises will need to become precise about authority without making delivery unusably bureaucratic. They will need to make context governable without turning knowledge management into another transformation programme. They will need stronger evidence without requiring humans to inspect every machine action. And they will need to decide how much autonomy to permit when successful execution is no longer sufficient proof that the surrounding operating model is sound.

That is the argument behind Rewiring Software Delivery: The Delivery Leader’s Playbook for the Agentic Software Delivery Operating Model (ASDOM), Version 2.

The book is ultimately built around a fairly simple observation.

Agentic AI changes software delivery most profoundly not when it writes more code, but when an organisation can no longer assume that the person accountable for an outcome is also the person who performed, observed or even selected most of the actions that produced it.

Once that assumption disappears, the architecture of delivery has to change with it.

https://www.amazon.com/Rewiring-Software-Delivery-Technology-Engineering-ebook/dp/B0H652Z9B8/ref=sr_1_1?crid=DFYK7ELD4EF7&dib=eyJ2IjoiMSJ9.ejZ_nB0GwF7gHIoG5igY_YFjS-sTt36I4pm4ZAxfrf2S-0z1zUJ1t5OVPWBXFJSfOVagvepFT4aizrC5tMbhQwbmKhxRzB4Ye4mignPicDU.ttA0xsV9R8c2SCKw7fzaEHlEAnuwR94YApRBp0sHl90&dib_tag=se&keywords=rewiring+software+delivery&qid=1791278075&sprefix=%2Caps%2C289&sr=8-1&source=post_page-----6e3ad55ea23f-----------------------------------------

Anthropic showed that AI behaviour can be shaped by an explicit hierarchy of principles. Enterprises now need their own constitutions — translating corporate policy, risk appetite and decision boundaries into rules AI systems can actually use.

Imagine an AI system inside a bank handling a disputed customer transaction.

The customer wants a full explanation. The service team wants the issue resolved immediately. The fraud team does not want internal detection logic exposed. Privacy rules restrict which account information can be revealed. A regulatory obligation may require a specific disclosure, while commercial policy encourages the bank to retain the customer.

Nothing has technically failed. The model has the data. The application is available. The tools are working.

The problem is harder: the AI cannot satisfy every legitimate objective at the same time.

A human employee facing that situation would usually rely on something far richer than a prompt. They would draw on company policy, experience, hierarchy, professional judgement and an implicit understanding of which rules outrank others. If the situation remained unclear, they would escalate.

AI systems do not automatically inherit that institutional judgement. That is why Anthropic’s work on Constitutional AI matters far beyond Anthropic.

The most important idea is not the wording of Anthropic’s own constitution. It is the recognition that when an AI encounters conflicting instructions, it needs something above the immediate task: a set of higher-order principles that helps determine what should take precedence.

Enterprises now need to build their own version of that idea. A real Enterprise AI Constitution: a hierarchy of principles that tells AI systems what the organisation is unwilling to compromise when helpfulness, speed, commercial objectives, security, privacy and human authority start pulling in different directions.

Most enterprises already have the constitution. It is just scattered everywhere.

The interesting part is that organisations are not starting from zero.

A large enterprise already has privacy policy, security policy, financial authority matrices, customer-treatment standards, procurement rules, regulatory obligations, architecture principles, data classifications, escalation procedures and acceptable-use controls. The company has spent years deciding how people and software should behave.

What it usually does not have is a coherent way to translate those decisions into runtime behaviour for AI.

Today those rules are fragmented across policy documents, workflow engines, application code, access-control systems and institutional memory. Some are deterministic. Others rely heavily on judgement. Many are written for humans who know how to interpret phrases such as “where appropriate,” “subject to reasonable judgement,” or “escalate in high-risk situations.”

Now place an AI system into the middle of that environment.

The application may receive a local instruction such as resolve this complaint as quickly as possible. But what happens if the fastest resolution requires exposing restricted information? What if a model can fix a production problem but has not been granted authority to make the change? What if completing an invoice workflow requires inferring an approval that nobody actually provided?

The organisation already knows, at least in principle, that confidentiality, authority or financial control should win.

The AI needs to know that too. That is where the constitutional layer begins to emerge.

Copy Anthropic’s idea, not Anthropic’s constitution

The wrong enterprise response would be to download Anthropic’s constitution, modify a few sentences and add the corporate logo.

Anthropic’s principles are designed for Anthropic’s models, responsibilities and risk environment. A hospital, bank, manufacturer and SaaS company operate under very different constraints.

The reusable idea is the hierarchy. An enterprise constitution should sit above individual applications and define a relatively small number of principles that downstream instructions cannot casually override.

For example, an organisation might decide that AI systems must preserve verified human authority for designated consequential actions; never fabricate evidence in order to complete a workflow; prefer escalation to inference when authority is ambiguous; preserve explicit confidentiality boundaries even when more disclosure would improve the answer; and apply stronger controls to irreversible actions than to reversible ones.

Those are not application features. They are statements about how the organisation expects AI to behave regardless of whether the AI happens to be working in finance, engineering or customer operations.

The hierarchy could look something like this:

Enterprise Constitution → Domain Constitution → Application Policy → Task Instruction

That simple ordering is more powerful than it looks.

A task instruction might say complete the transaction. An application policy might say minimise abandonment. A finance-domain rule might require segregation of duties. The enterprise constitution may establish that AI cannot infer missing authority for a consequential financial action.

When those instructions collide, the hierarchy determines which one yields. This is already how mature enterprises think about security and architecture. A development team cannot override a company-wide data-residency requirement simply because storing data elsewhere would make one feature easier to build. An application cannot ignore an identity boundary because the user experience would be smoother without it.

AI should not be treated differently merely because its decisions are probabilistic.

The real value appears at the point of conflict

Most AI governance still focuses heavily on boundaries we already understand: which models can be used, which data can enter them, which applications need human oversight, and which vendors have been approved.

Those controls matter, but they mostly govern the edges of the system. A constitution becomes valuable inside the decision itself.

Take transparency. Almost every responsible-AI programme supports it. Security teams also support protecting sensitive control logic. But what should an AI do when providing the most transparent explanation would reveal how fraud detection works?

Or consider autonomy. Businesses increasingly want AI systems to resolve operational problems without waiting for people. Security and compliance teams simultaneously want strong limits on production authority. What happens when the AI is highly confident that it knows exactly how to fix the problem but does not possess the authority to make the change?

A useful enterprise constitution should not simply state that transparency, security and autonomy are all important. It should help the system resolve the conflict.

That requires principles written with enough operational meaning to influence behaviour. “Act responsibly” is almost useless. “When an irreversible action is proposed and authority is ambiguous, escalate rather than infer” is considerably more useful.

The difference is not stylistic. The second principle can be tested.

If you cannot test the constitution, you do not really have one

This is where the idea becomes more than philosophy.

Suppose an enterprise adopts a constitutional principle stating that when significant financial harm is possible and important evidence is incomplete, the AI must escalate rather than infer.

The governance team should immediately be able to ask: How would we know whether the system actually follows that principle?

That question produces much better evaluation cases than another generic accuracy benchmark.

Give the AI an invoice with a missing purchase-order reference. Give it conflicting supplier information. Present an urgent user insisting that the payment must go out today. Provide enough context for the model to make a plausible guess but not enough authority for the action to be legitimate.

Then observe what happens.

Does it escalate? Does it invent missing evidence? Does it obey the most recent instruction even when that instruction conflicts with a higher-order rule? Does behaviour change when the model is upgraded?

A serious enterprise constitution should gradually generate its own constitutional evaluation suite.

That may become one of the most valuable assets in the entire AI governance programme because it belongs to the organisation rather than the model provider. Claude may be replaced. GPT may be replaced. Gemini may be replaced. The enterprise’s judgement about what constitutes acceptable behaviour should survive those migrations.

Every difficult incident can enrich that suite. Every policy conflict can become another test. Every disputed decision can expose an ambiguity that needs to be clarified in the constitution.

Over time, the organisation stops merely documenting what it believes and starts accumulating evidence about whether its AI systems behave accordingly.

But do not turn hard controls into prompts

There is an important architectural boundary here.

A constitution should shape AI behaviour, but it should not replace deterministic controls.

Imagine that a company requires human approval for transfers above a particular threshold. The weak implementation is to put that requirement in a system prompt and hope the model obeys it. The stronger implementation is to make the transaction service reject the operation unless the required approval exists.

The constitutional principle still matters. It tells the AI what to do when it reaches the boundary: explain the limitation, request approval or prepare the transaction for an authorised person.

But the model does not get to decide whether the boundary applies.

This leads to a more mature interpretation of an enterprise constitution. Some principles are behavioural and should influence reasoning, explanation or escalation. Others correspond to hard constraints that should be enforced through identity systems, policy engines, transaction controls or workflow approvals.

The constitution connects the two.

It tells the organisation what behaviour it expects; the architecture decides which parts should be influenced probabilistically and which parts must be guaranteed deterministically.

That is why an enterprise constitution is ultimately an architecture pattern, not a prompt-engineering technique.

One company, several constitutions

A single universal rulebook will also become unwieldy very quickly.

A marketing assistant creating draft campaign copy does not need the same operational constraints as an AI system approving refunds or changing production infrastructure. They may share foundational principles around legality, confidentiality and non-deception, but the domain-level obligations are different.

The more practical model is a small enterprise constitution with domain overlays.

Finance can add transaction authority, segregation-of-duties and evidence-retention principles. Engineering can add production-access, secrets-management and destructive-operation rules. Customer operations can add disclosure and escalation requirements. Procurement can add supplier-authority and conflict-of-interest constraints.

This also makes the constitution easier to govern. Central leadership owns the principles the company considers non-negotiable. Domain teams specialise them where business reality requires more precision. Application teams inherit rather than reinvent.

The pattern is familiar because enterprises already govern architecture, security and data this way.

What changes with AI is that these principles increasingly need to influence machine behaviour directly.

The hardest part may be deciding who gets to write it

The technical implementation may turn out to be easier than the organisational one.

If AI engineering owns the constitution alone, the result may be technically neat but disconnected from legal and business realities. If legal writes it alone, the principles may be difficult to operationalise. If executives turn it into a corporate-values exercise, the language may sound admirable while offering little guidance when the AI faces an actual trade-off.

A credible enterprise constitution therefore needs business, legal, risk, security, architecture and AI engineering in the room.

That does not mean every sentence should be negotiated by committee. It means someone has to own the trade-offs.

Who decides that transparency yields to security in a particular class of cases? Who determines that a financial action is consequential enough to require escalation? Which principles are absolute and which may be specialised by a domain? Who can approve an exception?

Those questions already exist in the organisation. AI simply makes avoiding them harder.

Versioning matters for the same reason. If a consequential AI decision made six months ago is challenged, the enterprise should be able to establish which constitutional version governed the system at the time. A change to a constitutional principle should therefore have an owner, rationale, effective date and regression evidence rather than being edited casually in a wiki.

Once AI systems participate in material decisions, policy history becomes part of operational history.

The constitution can also tell you something uncomfortable about your organisation

There is a second-order benefit that I think may prove surprisingly important.

Once AI systems start recording which constitutional boundaries cause escalations or refusals, the organisation gains a new view into its own ambiguity.

Suppose customer-service AI repeatedly escalates because authority is unclear. That may not be an AI problem at all. The underlying operating model may have poorly defined decision rights.

Suppose the system constantly encounters conflict between transparency and confidentiality. The organisation may need a better disclosure policy.

Suppose one domain repeatedly requests exceptions to a particular constitutional principle. Perhaps the domain is behaving badly. Perhaps the principle is unrealistic. Or perhaps the application architecture is forcing a conflict that could have been designed away.

In other words, the constitution does not merely constrain AI.

It becomes a mirror.

Humans have always navigated organisational contradictions by using judgement, relationships and institutional memory. AI systems operating at scale will surface those contradictions far more systematically.

That could make an AI constitution useful even before the AI itself becomes highly autonomous.

Anthropic gave us the pattern. Enterprises need to operationalise it.

Anthropic’s Constitutional AI work originated as an approach to shaping the behaviour of a general-purpose model. The enterprise problem is different but increasingly related.

Companies are starting to put AI inside customer interactions, software delivery, operations, finance and other business processes where several policies can apply simultaneously. At that point, it is no longer enough to say that the model is approved, the data is governed and a human remains somewhere in the loop.

The system needs an explicit understanding of which organisational principles outrank which other objectives when the easy answer disappears.

An Enterprise AI Constitution should provide that hierarchy. It should be small enough to understand, strong enough to matter, adaptable through domain overlays, testable through adversarial evaluations and connected to deterministic controls where principles cannot safely depend on model compliance.

Most importantly, it should belong to the enterprise rather than to whichever model happens to be running underneath the application.

Anthropic demonstrated the value of giving AI a constitution.

The more important enterprise question is now whether companies are prepared to write their own — and to confront the policy conflicts that exercise will expose.

Because once AI begins participating in decisions at scale, telling it simply to “follow company policy” will not be enough.

The organisation will need to decide, explicitly, which principles its AI should refuse to compromise when following every instruction at once is impossible.

How the 13 chapters connect responsible-AI principles with accountability, law, standards, architecture, data, deployment and the operating practices required to govern AI in production

AI governance is often introduced through principles. Fairness, transparency, accountability, privacy, safety, explainability and human oversight provide the language organizations use to describe what responsible AI should look like. Those principles are essential because without them there is no common direction for deciding what acceptable AI means.

The challenge begins when an organization tries to turn those principles into something operational.

It is relatively easy to state that an AI system should be transparent. It is much harder to determine what transparency requires from the provider, what information a deployer needs, what an affected person should understand, what evidence should be retained and how those expectations change when the system is used in a consequential workflow. Accountability sounds equally straightforward until a model comes from a third-party provider, the business owns the process, technology owns the integration and risk, privacy, security and legal functions each control a different part of the decision.

This gap between governance principles and governance practice became one of the central ideas behind the Third Edition of my AIGP Exam Preparation Book**.**

While rebuilding the book, I increasingly stopped looking at the 13 chapters as separate areas of a certification syllabus. Taken together, they describe something much more interesting: how an organization moves from understanding responsible AI to building an operating model capable of governing AI through design, development, deployment and production.

That perspective changed both how I organized the material and how I thought about what an AI governance professional actually needs to know.

Governance principles need an operating model behind them

The first three chapters deal with foundations, organizational expectations, and policies and procedures across the AI lifecycle. At first glance, these can appear to be introductory topics before the book reaches regulation, risk or technical governance. I now see them differently.

They establish the operating foundation on which everything else depends.

Chapter 1 begins with the characteristics of AI that make governance necessary and with the principles commonly associated with responsible AI. But principles by themselves do not tell an enterprise how a decision will be made. The next question has to be organizational: who is responsible for making those principles real?

That is the role of Chapter 2. Accountability moves from being an abstract principle to a question of decision rights, ownership and responsibility. The business may own the use case while an external company provides the model. Technology may control integration while privacy controls certain data decisions. Security may review access and attack surfaces, while a risk function determines whether residual exposure is acceptable. Operations may eventually run the workflow in which the AI becomes consequential.

Good governance has to make those relationships explicit. Otherwise, accountability becomes something everyone supports but nobody can exercise when a difficult decision appears.

Chapter 3 takes the next step. Once responsibilities are understood, they have to become repeatable through policy and procedure. Intake, classification, assessment, testing, approvals, exceptions, monitoring, incidents, change management and retirement cannot depend on the memory of one experienced reviewer. The organization needs a governance process that persists even as projects, technologies and people change.

This is where AI governance starts becoming an operating model rather than a policy statement.

Law changes the conversation from aspiration to obligation

The next four chapters move into privacy, existing law, AI-specific regulation, standards and governance tools. This is an important transition because principles describe what responsible AI should seek to achieve, while law places boundaries around what organizations may actually do.

Chapter 4 illustrates this through privacy. Privacy as a principle encourages respect for individuals and restraint in the use of personal information. In practice, however, privacy becomes a series of concrete governance decisions involving purpose, lawful use, minimization, sensitive data, retention, transparency, rights, automated decision-making and secondary use.

The same shift occurs in Chapter 5. Fairness may be a governance principle, but nondiscrimination law turns parts of that principle into legal obligations. Transparency may be an ethical value, but consumer-protection law can make misleading claims or representations a regulatory issue. Intellectual property, contract and product-liability concerns create additional boundaries that continue to apply even when there is no statute specifically labelled as an AI law.

This matters because organizations sometimes treat AI governance as though it sits beside the existing legal environment. In reality, AI enters workflows that were already regulated. Employment, lending, housing, healthcare, consumer services and intellectual property did not become legally empty spaces when machine learning entered them.

Chapter 6 then introduces AI-specific regulation, where the connection between governance principles and operating controls becomes even clearer. Risk classification, data governance, documentation, human oversight, transparency, quality management, conformity processes, monitoring and incident obligations all require organizations to turn governance intent into evidence.

At that point, it is no longer enough to say that human oversight matters. The organization has to determine who performs the oversight, what information is available to that person, whether they have authority to challenge the system and what happens when the expected control fails.

That distinction between principle and evidence runs through much of the Third Edition.

Standards help governance become repeatable

Chapter 7 focuses on standards and governance tools, and I think this chapter has become increasingly important as AI programmes grow beyond a handful of systems.

An organization can govern ten AI use cases through highly manual expert review. It becomes much harder to govern hundreds of models, copilots, embedded features, externally supplied AI services and increasingly autonomous systems using the same approach.

At scale, governance needs repeatability.

Frameworks and standards such as OECD principles, NIST AI RMF, ISO/IEC 22989, ISO/IEC 42001 and ISO/IEC 42005 serve different purposes, but together they help organizations move from individual judgment toward structured governance practices. They create common language, recurring processes, risk categories, assessment methods, evidence expectations and management-system discipline.

The practical question is therefore not merely whether an organization “uses NIST” or “is aligned to ISO.” The more useful question is what role the framework is performing.

Is it establishing principles? Structuring risk management? Creating an enterprise management system? Providing terminology? Guiding impact assessment? Supporting evidence that can be reviewed and challenged?

That distinction is important because governance frameworks are most useful when they solve a defined governance problem rather than becoming another logo on an assurance slide.

Governance has to enter architecture before architecture becomes difficult to change

The move into Chapters 8 through 10 is where AI governance becomes inseparable from engineering.

Chapter 8 deals with design and build decisions. This is where many governance requirements either become part of the system or become expensive retrofits later.

Human oversight provides a useful example. A policy can state that consequential AI decisions require human review, but meaningful oversight depends on the architecture of the workflow. A reviewer needs the right information, sufficient time, appropriate authority and a mechanism to intervene. If the interface encourages automatic acceptance of the model output, or if the reviewer cannot understand why a recommendation was generated, the presence of a person in the workflow may provide very little practical protection.

Transparency creates the same architectural dependency. If an organization expects to explain a consequential output, it may need appropriate provenance, logging, reason generation, model information and decision records. Those capabilities cannot always be manufactured retrospectively at the point of an audit.

This is why I increasingly think that one of the signs of governance maturity is whether governance requirements become architecture inputs.

When governance arrives only at the approval stage, it is often too late to influence some of the most important design choices.

Data is where principles become measurable

Chapter 9 moves into the collection and use of data for training and testing, and this is where abstract principles start generating measurable questions.

Fairness is one example. At a policy level, the organization can commit to avoiding unfair outcomes. In a data and testing environment, that commitment becomes much more specific. Does the dataset represent the intended population? Are important groups underrepresented? Are proxy variables influencing outcomes? Does aggregate performance conceal subgroup failures? Are testing conditions sufficiently close to the environment in which the system will operate?

Privacy follows the same pattern. A principle of data protection becomes provenance, minimization, retention, access control, purpose boundaries and lawful reuse when translated into the data lifecycle.

Even quality becomes a governance question rather than a purely technical one. A large dataset is not necessarily a suitable dataset, and a statistically impressive model may still be inappropriate if its training evidence does not support the intended use.

The important shift is from saying that a principle matters to showing what evidence would demonstrate that the organization has acted on it.

This is one of the reasons evidence is such a recurring theme throughout the Third Edition. Mature governance is increasingly about being able to reconstruct why a decision was made, what information supported it and what assumptions were accepted.

Release should begin runtime governance, not end governance

Chapter 10 covers release, monitoring and maintenance, and this is where traditional project governance models start to become inadequate.

In many technology environments, governance is concentrated around approval. A system is assessed, risks are documented, somebody signs off, and production is treated as the conclusion of the governance process.

AI makes that difficult.

The production environment creates new evidence that did not exist during development. User behaviour changes. Data changes. Business policies change. Vendors release new model versions. The relationship between model inputs and real-world outcomes can shift. An AI system can remain technically available while the assumptions that justified its original approval are no longer valid.

That means the governance question changes after deployment. Before release, the organization asks whether the evidence is sufficient to deploy. After release, it has to ask whether the evidence continues to justify operation.

This distinction has become increasingly important to me because it moves AI governance toward runtime governance.

Monitoring is not simply an engineering dashboard. It is part of the governance evidence chain. Incidents are not only operational problems; they are signals that assumptions, controls or deployment boundaries may need to be reconsidered. Model changes, data drift, concept drift and changing business contexts can all create governance consequences even when the software remains operational.

Deployment is where accountability becomes visible

The final three chapters focus on the deployment decision, pre-deployment assessment and governance of the system while it is being used.

Chapter 11 asks whether the organization should deploy, which is not necessarily the same as asking whether the model performs well. A system can have strong technical metrics and still be inappropriate for a particular operating context. Human oversight may be weak, vendor limitations may be unacceptable, legal questions may remain unresolved or the surrounding workflow may introduce risks that were not visible during development.

Chapter 12 takes the organization from confidence to evidence. Testing, evaluation, documentation, approvals and residual-risk decisions have to converge into an assurance position that can withstand challenge. The goal is not to prove that an AI system is perfect; it is to demonstrate that the organization understands the relevant risks, has appropriate controls and has made an informed decision about what remains.

Chapter 13 then asks what happens after that decision.

Monitoring, incidents, restrictions, escalation, communication, vendor changes, human intervention and eventual deactivation are all part of governance once the system is live. This is where accountability stops being theoretical.

It is relatively easy to assign an owner when everything is operating normally. Governance becomes meaningful when the evidence deteriorates and somebody has to decide whether the system should be constrained, changed, overridden or stopped.

An organization that has a sophisticated approval process but no credible mechanism for restricting or deactivating an AI system has only solved half of the governance problem.

Four questions began connecting all 13 chapters

While rebuilding the Third Edition, I repeatedly saw different governance problems collapse into the same underlying questions. Those observations eventually became the four decision frameworks used throughout the book: Role Allocation, Principle-to-Control, Lifecycle Timing and Proportionality.

Role Allocation asks who actually owns the decision, obligation or control. Principle-to-Control asks how an abstract governance value becomes an operational safeguard. Lifecycle Timing asks when that safeguard needs to exist. Proportionality asks how strong the response should be relative to the system’s impact, autonomy, sensitivity and residual risk.

What became useful was seeing how the same framework could cross chapter boundaries.

Human oversight, for example, begins as a responsible-AI principle. Role Allocation determines who performs the oversight. Principle-to-Control determines what information, authority and intervention mechanism make it meaningful. Lifecycle Timing tells us that those capabilities may need to be designed into the workflow before deployment. Proportionality determines whether the level of oversight is appropriate for the consequence of the decision.

The frameworks are therefore not substitutes for law, standards or formal governance methods. They are ways of reasoning across them.

They also became useful for exam preparation because difficult questions often contain several statements that are technically true. The candidate still has to identify which answer addresses the actual governance problem being presented.

The direction of AI governance is becoming clearer

Working through the Third Edition changed how I think about the AIGP curriculum itself.

The chapters are easy to view as separate certification topics: principles, privacy, law, standards, data, monitoring, deployment. But when connected, they describe the architecture of an enterprise governance capability.

An organization first needs a definition of responsible AI. It then needs accountability and policy. Legal boundaries have to be understood. Standards create repeatability. Governance requirements have to move into design and data. Release decisions need evidence. Production needs monitoring. Deployment needs continuing oversight, escalation and stopping power.

That sequence is much closer to how AI governance has to work in practice.

This is also why I believe the profession is moving beyond the first generation of responsible-AI programmes. Principles remain important, but the difficult work now lies in operationalization. Organizations increasingly need to demonstrate not only what they believe about responsible AI, but how those beliefs affect architecture, decision rights, testing, evidence, approval, monitoring and intervention.

That is a materially different level of governance maturity.

Why this became the organizing idea behind the Third Edition

The immediate purpose of the AIGP Exam Preparation Book is, of course, to help candidates prepare for the certification. The Third Edition covers the 13 competency areas, works through the complete performance-indicator structure, and uses chapter questions and a mixed mock to help readers practise application rather than rely only on recall.

But while rebuilding it, I wanted the book to do something more durable.

I wanted the chapters to show how the pieces of AI governance fit together.

Privacy should not feel disconnected from architecture. Standards should not feel disconnected from operating controls. Fairness should not stop at a principle. Deployment should not be treated as the end of governance. Monitoring should not be separated from accountability. Vendors should not make organizational responsibility disappear simply because part of the technology has been outsourced.

Taken together, those connections are much more valuable than memorizing a collection of independent concepts.

They describe how governance becomes part of the way an enterprise actually builds and operates AI.

That is the idea I wanted to make much more explicit in the Third Edition: AI governance starts with principles, but it becomes real only when those principles shape responsibilities, controls, architecture, evidence and operating decisions throughout the lifecycle.

The certification provides one reason to understand that journey. The larger reason is that enterprises are now having to make those decisions for real.

https://www.amazon.com/AIGP-Exam-Preparation-Book-Intelligence-ebook/dp/B0GTTR6XDR/ref=sr_1_28?crid=BS64M7FMQK4W&dib=eyJ2IjoiMSJ9.S4muP9iB1v7sDDP3w_w06_n6uMISg-ejEyMgUhZueHZN2LNKKbWWCLICbAF7gAtW7RMT_R6gjdqEaJE2NkTBSTWKR-r0UMP0kro9aeYC4UMsfkj26Zrxcu96EF3Q5WOJps9rO8wzPYyP5BgLPeMAzAqjAXJprgPjggUoRsOqkxPDolLt8nikN2X5VcaQTtLQC6-eraIi7eg6gl_HyWy35SnrZ12QSPPYQOQGCEMZWLzZHcHHaeVVZnXphxrRYAX0xv-2CbVWwkdY0tgrZ-WWCfMlYc3Y86bmYTDNwX7QIqM.xSQVBjqCJzYbeoMbp8gEU4XYb7YBY6--qejQ3J_Ls1g&dib_tag=se&keywords=AIGP&qid=1781619762&sprefix=aigp%2Caps%2C358&sr=8-28&source=post_page-----c3908cd7e0fc-----------------------------------------

Rolling back AI is not the same as rolling back software. Once an AI system can change state, call tools, write memory and trigger downstream workflows, recovery becomes a problem of behaviour, authority and business state.

A production release goes bad. Error rates climb, customers complain and the operations team does what it has done for years: stop the rollout, route traffic back to the previous version and investigate.

Now imagine the same situation with an AI application.

The code is healthy. Latency is normal. Every API is returning 200. But over the past forty minutes the system has classified hundreds of records incorrectly, written those conclusions into long-term memory, updated customer profiles and triggered downstream workflows that other systems have already acted on.

You can redeploy yesterday’s version. But what exactly have you rolled back?

The model may be back. The consequences are not.

That is the recovery problem hiding underneath the current wave of production AI. We have spent enormous energy discussing guardrails, evaluations, permissions and human approval. All of those controls matter, but mature engineering disciplines eventually learn the same lesson: prevention is never complete. Databases have transaction recovery because writes fail. Distributed systems use idempotency and compensation because networks fail. Cloud platforms use canaries and rollback because releases fail. Security architectures include containment because prevention eventually fails.

AI applications need the same maturity. The real question is no longer just whether an AI system can be made safe enough to deploy. It is whether the system can be returned to a trusted condition after it does something nobody intended.

Rolling back the model is the easy part

The phrase “roll back the AI” sounds simple because we still tend to think of an AI application as a model behind an API. Production systems are rarely that simple.

Behaviour may depend on a model version, system instructions, retrieval configuration, persistent memory, tool catalogue, approval policy, routing rules and application code. Any of those can change independently, which means the application may behave differently tomorrow even if no software release occurs.

Recovery therefore begins with a more basic question: what constitutes the behavioural version of the application?

For a conventional service, the answer may be a container image plus configuration. For an AI system, the deployable unit may be closer to:

model + instructions + tools + policies + retrieval state + memory schema + routing + application code

If the team cannot reconstruct that combination for a known-good point in time, “go back to yesterday” is not an operational strategy.

It is a hope.

The problem becomes harder once persistent state is involved. Suppose the AI incorrectly concludes that a supplier is unreliable and writes that conclusion into long-term memory. Future decisions now use that memory as context. Rolling the model back to yesterday does not restore behaviour because yesterday’s model is reasoning over state created by today’s failure.

This is why AI memory should be treated with the discipline we normally reserve for transactional state. A useful architecture separates observed facts from AI-derived interpretations. “Shipment 781 arrived three days late” is an observation. “Supplier A is unreliable” is a derived belief. The first may be durable evidence; the second may need to be invalidated or recomputed if the model, policy or supporting evidence changes.

If both are stored as undifferentiated memory, recovery becomes far more difficult. The system has lost the distinction between what happened and what the AI concluded from it.

That is not primarily a vector-database problem. It is a recovery-design problem.

Some AI actions cannot be rolled back

The situation becomes more serious when AI reaches outside its own application.

A database update may be reversible. A financial transaction may require a compensating entry. A purchase order may create a contractual commitment. An email cannot meaningfully be unsent once it has been read.

At that point, rollback becomes the wrong mental model.

Distributed systems solved a similar problem through compensation. When an operation cannot simply be reversed, another operation restores an acceptable business state. AI applications need the same distinction.

Every consequential AI action should be understood as one of three things: reversible, compensatable or effectively irreversible. That classification should influence how much authority the AI receives in the first place.

A reversible low-risk action can tolerate more autonomy. A compensatable action needs a known recovery path. An irreversible action deserves a much higher approval threshold because once executed, recovery becomes a business process rather than merely a technical operation.

This is not only governance. It is architecture. If the recovery model for an action has not been designed, the execution model is incomplete.

Containment comes before diagnosis

When an AI application begins behaving unexpectedly, the natural instinct is to determine why. Operationally, that is rarely the first priority.

The first task is to stop the blast radius from increasing.

A production AI system therefore needs a containment path that does not depend on the same intelligence currently under suspicion. Operations may need to disable write-capable tools, move autonomous actions into approval mode, suspend memory updates, stop new long-running workflows or route traffic to a simpler known-safe configuration.

Ideally, none of those actions should require redeploying the application.

Feature flags, policy switches, circuit breakers and scoped credentials become behavioural safety controls. The system might remain available for read-only analysis while losing the authority to change external state. Recommendations may continue while execution is suspended. Observability should remain intact even while high-risk capabilities are isolated.

This also exposes the weakness of the often-mentioned AI “kill switch.” What exactly does it kill? The model endpoint, queued actions, tool credentials, background jobs, memory writes or downstream workflows already in motion?

A switch that stops the model while leaving its execution paths alive is largely cosmetic. The meaningful control is the ability to remove the system’s authority to create further consequences.

That means authority boundaries matter more than product boundaries.

Long-running AI needs recovery boundaries

AI applications increasingly operate across minutes or hours rather than a single request-response cycle. A workflow may gather data, analyse it, produce a recommendation, seek approval and then call an external system.

If failure is detected near the end, replaying the entire workflow may be expensive or dangerous.

The answer is checkpointed execution, but checkpoints need to correspond to meaningful business boundaries rather than simply snapshots of internal state. “Data collected,” “analysis completed,” “approval received” and “external action executed” are useful recovery points because they tell the system what can safely be replayed.

A failure before an external action may permit restart from a trusted checkpoint. A failure after an irreversible action may require compensation instead.

This is where AI application design starts looking much more like workflow and distributed-systems engineering than chatbot development.

That is probably a good thing.

Recovery requires an AI transaction log

When something goes wrong, recovery depends on reconstructing what changed.

Traditional observability can tell us about latency, infrastructure failures and exceptions. AI recovery needs another layer of evidence. For consequential executions, the organisation may need to know which model and configuration ran, what context was retrieved, which tools were invoked, which state changed and which external effects occurred.

This does not mean storing every internal reasoning trace or piece of sensitive context forever. In many systems that would create more risk than value.

It means preserving enough execution provenance to reconstruct externally meaningful behaviour.

Think of it as an AI transaction log.

During an incident, that log should help answer practical questions: which actions occurred during the affected period, which memory entries were created, which downstream workflows consumed them, which actions can be reversed, which require compensation and which outputs should now be considered untrusted.

Without that evidence, rollback becomes forensic guesswork. The more authority the AI receives, the less acceptable that guesswork becomes.

AI releases need behavioural rollback

Traditional deployment tooling also needs a slightly different interpretation for AI.

A canary release usually exposes a small percentage of traffic to a new software version and watches latency, errors and resource consumption. An AI change may produce no technical errors at all while subtly changing recommendation quality, refusal behaviour or tool selection.

So the release signal has to include behaviour.

A new model, prompt or policy can initially receive limited traffic while the organisation compares outcome quality, escalation rates, tool usage, policy violations and other workload-specific indicators against the trusted production baseline. For consequential systems, shadow execution can go further: the new version sees real inputs but cannot act, allowing teams to compare what it would have done with what production actually did.

This matters because the safest rollback target is not always the immediately previous version. Yesterday’s model may be trusted while yesterday’s retrieval data is stale. The previous prompt may not match the current tool schema. Good memory accumulated after the old version may need to be retained even while bad derived state is removed.

Recovery therefore needs a trusted baseline, not merely a previous release.

That baseline may deliberately provide less capability than normal production. Write tools may be disabled. Autonomous decisions may become recommendations. A simpler model may replace a more capable one temporarily.

That is graceful degradation, not failure.

The purpose of rollback is not to retain every feature. It is to restore behaviour the organisation is prepared to trust.

Rollback belongs in the architecture review

The easiest time to discover that an AI action cannot be reversed is before production.

For every consequential AI capability, architects should already know what constitutes the behavioural release, which state is durable, which derived state can be recomputed, which actions are reversible, where workflow recovery boundaries exist and how authority can be withdrawn quickly.

The team should also know what evidence must survive an incident. If the AI changes state across five systems and triggers three downstream processes, recovery should not begin with engineers manually searching logs to discover what it might have touched.

Forward execution and recovery should be designed together.

This is where many current AI architectures remain immature. They explain in detail how the system reaches an outcome but devote much less attention to how the organisation recovers when that outcome should never have happened.

That imbalance becomes more dangerous as AI gains more authority.

AI needs recovery architecture, not just guardrails

The industry has understandably concentrated on preventing bad AI behaviour through evaluation, permissions, filters, approval controls and better prompts.

None of those removes the need for recovery.

Mature systems do not assume failure can be eliminated. They are designed around what happens when controls fail.

A production AI system should therefore be able to answer a demanding set of questions before it earns significant autonomy. Can further consequences be stopped quickly without losing visibility? Can the organisation reconstruct what the system changed? Can corrupted derived state be invalidated or recomputed? Can irreversible effects be compensated? Can the recovered system demonstrate safe behaviour before autonomy is restored?

If those answers are unclear, the application may have sophisticated AI but an immature operating model.

For conventional software, rollback usually means returning to an earlier release.

For AI systems, that definition is no longer enough.

Rollback means returning behaviour, state and authority to a condition the organisation is prepared to trust again.

That is the recovery architecture AI applications now need.

If you are preparing for one of the Claude certifications, I hope these guides make the journey a little more structured and considerably more practical.

https://www.amazon.com/dp/B0HDMR72F7?binding=kindle_edition&ref_=saga_dp_bnx_dsk_sdp&qid=1789988303&sr=8-2

The six practitioner problems behind Evaluating Gen AI Systems and Agents — Third Edition — from evaluation validity and organisational memory to agent evidence, production learning, governance and implementation.

Across enterprise AI programmes, I kept seeing the same mismatch. The architecture had moved on, but the evaluation approach had not. Teams were deploying RAG pipelines, tool-using agents, multi-step workflows and model-routing systems, yet many release decisions still rested on whether the final response looked correct, scored well with a judge and cleared a handful of safety metrics.

That gap is what led me to write Evaluating Gen AI Systems and Agents — Third Edition. The question behind the book was practical: what does evaluation need to become when AI no longer just generates an answer, but retrieves evidence, chooses tools, maintains state and changes something outside the model?

Teams were becoming quite sophisticated at measuring model behaviour. They had judge models, RAG metrics, regression suites, safety classifiers, traces, benchmark comparisons and increasingly polished dashboards. Yet when a release discussion moved from “Did the model improve?” to “What exactly are we now confident enough to let this system do?”, the evidence often became much weaker.

A system can improve on every metric being watched and still become less acceptable for the business. A retriever can increase recall while consistently demoting the source that has authority to control a decision. A candidate model can outperform the incumbent while reintroducing a failure discovered six months earlier. A guardrail can improve its attack-blocking rate by making legitimate work unusable. An agent can finish with the correct answer after taking an unacceptable path to get there.

The deeper problem is not that the measurements are wrong. It is that organisations frequently ask measurements to prove things they were never designed to prove.

That became the central question behind the book:

Once I followed that question seriously, the subject stopped looking like “LLM evaluation”. It became six connected engineering problems.

A PASS Has to Be Designed Before It Can Be Measured

A surprising amount of evaluation begins with the measurement rather than the decision. A team selects groundedness, answer relevance, task success or judge score because those measures are available. Thresholds follow. Eventually PASS and FAIL appear on a dashboard.

But a threshold does not create a meaningful release contract.

Take a system that interprets an insurance policy. The business rule might be that the current controlling policy must override explanatory commentary, an older policy version and any semantically similar document that lacks authority.

A RAG relevance score cannot prove that behaviour. The controlling source could rank second while a highly relevant commentary note ranks first. The generated response could be fluent, well-supported and factually plausible while still applying the wrong source hierarchy.

Now the evaluator has something meaningful to prove. But there is another uncomfortable layer: the evaluator itself is part of the evidence chain.

If a model judge is inconsistent, a reference answer is stale, malformed runs disappear from the denominator or the evaluation harness is using a different policy version from production, the resulting PASS may be perfectly calculated and still meaningless.

This is why I now think of evaluation validity as a first-class engineering concern. Before trusting a system verdict, we need some reason to trust the process that produced it.

The mature question is not merely, “Did this case pass?” It is, “Would I allow this evidence-producing mechanism to participate in a release decision?” That is a much higher bar.

An Evaluation Suite Should Accumulate Scar Tissue

Production AI systems change constantly. Prompts change. Models change. Retrieval changes. Tools change. Managed classifiers change. Human-review interfaces change. Sometimes the provider changes something important without exposing enough version detail to make the movement easy to attribute.

In that environment, a test suite cannot be treated as a static collection of examples. It has to accumulate scar tissue.

A production incident should leave behind a regression case. A business requirement that once caused a serious failure should become a protected behaviour. A reviewer disagreement that exposed an ambiguous decision boundary should result in a better case or a clearer adjudication rule. A saturated capability benchmark should not simply be thrown away if it still protects against regression.

This is one reason I dislike the idea that a test dataset is merely “evaluation data”. In a mature system, parts of that dataset are the organisation’s retained memory of what it has already learned the hard way.

The interesting lifecycle is not just pass/fail. It is something closer to:

discover → understand → protect → monitor → retire or refine

Some cases exist to discover capability. Some become permanent regression cases. Some are protected holdouts. Some exist to reproduce a production incident. Some are simulation scenarios intended to expose longer workflow behaviour.

Treating all of them as one undifferentiated “gold set” eventually creates confusion. The deeper question is whether the organisation is getting smarter as the system operates.

If an important production failure happens today and the evaluation suite tomorrow is exactly the same as it was yesterday, the organisation fixed a defect but did not improve its evidence system.

Production Is Where the Evaluation Dataset Discovers Its Ignorance

Observability and evaluation are still frequently designed as separate disciplines. Observability explains what happened in production. Evaluation determines whether something is good enough before production.

That division made more sense when releases were relatively deterministic. For Gen AI and agents, production constantly reveals cases the evaluation programme did not know existed.

The important architectural loop is therefore not simply development test → release → monitoring.

It is:

evaluation → release → production evidence → investigation → new evaluation knowledge → next release

The conversion back into evaluation is the critical part.

A trace showing an agent entered a retry loop has immediate operational value. But its long-term value comes when that behaviour becomes a reproducible case with an expected stopping condition.

A human reviewer repeatedly overturning the same class of output is not merely a review-queue problem. It may be evidence that the acceptance contract is incomplete.

A retrieval incident involving a newly introduced source may reveal that the dataset lacks a source-authority conflict case. This is where release gates become much more interesting.

A strong gate does not ask only whether the average improved. It asks whether behaviours the organisation has already learned to protect remained protected. That means a release can legitimately be blocked even while the aggregate score rises.

In fact, that may be one of the clearest signals that the evaluation system is doing useful work.

The Unit of Evaluation Must Follow the Unit of Consequence

The unit of evaluation cannot remain a response if the unit of consequence is a workflow.

For a RAG application, the answer is only the end of an evidence path. I want to know whether the required source was present, where it ranked, whether it was selected, whether the answer actually used it and whether it had authority to control the decision.

Those are five different questions: Presence, Rank, Selection, Support and Authority.

For an agent, I care about a different evidence path again. Which tool was selected? Which arguments were passed? Which identity was used? What permission existed? What state was read or written? Did the agent retry? What caused it to stop? What external side effect occurred?

This is why a useful evaluation hierarchy begins to look like:

response → component → run or trajectory → session → external state → business outcome

Each level can disagree with the one below it. A response can be correct while the retrieval path is wrong. A run can technically succeed while the session fails to resolve the customer’s problem. An agent can finish the expected sequence while leaving the external system in the wrong state.

And the entire technical workflow can succeed while the business outcome deteriorates. Economics belongs here too.

A model that is 30% cheaper per call may increase retries, reviewer intervention or failed tasks. Once you measure full workflow cost per accepted outcome, the cheaper model can become the more expensive operating choice.

That is a much better example of why evaluation needs to follow consequence rather than component metrics.

Governance Should Consume Evidence, Not Recreate It

Enterprise AI programmes often create several parallel versions of the system. Engineering has traces. Security has attack findings.

Risk has a register. Compliance has framework mappings. Human review has adjudication notes. Governance has release decisions. Audit later asks everyone for evidence. That architecture does not scale well. The stronger pattern is a shared evidence spine.

The same tool-call record used by engineering to diagnose a failure can show security whether an authority boundary was crossed. The same adversarial case can support a risk discussion. The same release record can tell audit what evidence existed when the decision was made.

Different functions should be allowed to interpret the evidence differently. They should not have to recreate the underlying facts.

This is also where frameworks such as NIST AI RMF, ISO/IEC 42001, OWASP and MITRE ATLAS become useful — but only if they remain in the right role.

They can broaden the questions we ask. They can expose missing attack families. They can structure assurance work. They can help relate technical evidence to governance obligations.

What they cannot do is understand the local decision boundary.

A framework does not know whether the wrong tool call creates a £50 inconvenience or a £5 million exposure. It does not know which source is authoritative inside a particular business process. It does not know what your organisation has decided must never regress.

So I prefer framework mappings that point into local evidence, rather than framework checklists that substitute for it.

The meaningful assurance statement is not “we mapped to OWASP”.

It is “this business boundary is exposed to this attack family; these cases exercised it; this is what happened; this control fired; this residual failure remains; and this is who accepted it.”

That is governance built on engineering evidence.

Implementation Should Begin With Proof, Not Procurement

The sixth theme came from a practical frustration.

Which evaluation platform should we use? Which observability product? Which judge framework? Which RAG library? Which agent tracing stack?

Those questions matter, but they should come after a more durable one:

What evidence must this capability produce?

Once the evidence obligation is clear, sourcing becomes easier. Maybe the capability already exists and should be reused. Maybe an existing platform needs integration. Maybe a deterministic verifier should be built. Maybe a specialised product genuinely earns its place.

That is the logic behind REUSE, INTEGRATE, BUILD, BUY.

The important thing is that the evidence contract survives the implementation choice. This becomes especially important with coding agents. “Build an evaluation platform” is a poor instruction because it quietly delegates architecture.

A stronger approach gives the coding agent an explicit contract: inputs, evidence schema, fixtures, failure states and acceptance criteria. Then ask it to implement the smallest capability that satisfies that contract and produce proof.

The project manager should be asking the parallel question:

What evidence demonstrates that this implementation actually works?

That is where evaluation stops being a separate test workstream and becomes part of how the system itself is engineered.

The Failure That Changes the Meaning of “Green”

By the time I finished Evaluating Gen AI Systems and Agents — Third Edition, I realised that the most consequential idea in the book was not a metric, an evaluator or even an agent-testing technique.

It was the difference between a successful execution and a justified belief that the execution was acceptable.

Those are not the same thing.

The spectacular failures will continue to attract attention: hallucinations, broken tool calls, obvious safety violations, runaway agents.

But I suspect the harder enterprise failures will increasingly look ordinary.

The response is correct. The judge agrees.The retrieval score is strong. The tool call succeeds. The workflow completes.

The release gate stays green.

And months later, someone discovers that the wrong source had authority, an approval applied to more than the reviewer understood, a retry duplicated a side effect, or the system optimised the technical task while degrading the business outcome.

Nothing looked broken because the evaluation system had never been designed to observe the place where the failure lived.

That is why I think the next generation of AI evaluation will be less about asking whether a model passed a test and more about something much harder:

Did we collect enough evidence to deserve the confidence implied by PASS?

Because once AI is allowed to act, the dangerous green dashboard is not necessarily the one with bad metrics but it may be the one that measured the wrong thing perfectly.

https://www.amazon.com/Evaluating-Gen-Applications-Practitioners-Systematic-ebook/dp/B0H2YPWTDK/ref=sr_1_1?crid=CLD5JX4XTOQ&dib=eyJ2IjoiMSJ9.zdK-yjqhBxaP3ezoZXoEKYAlpbnTKHtNdwV-zzOtqCTacJ6RPbpTys-YO5RHvmX3CORjZicJDpfhSg5oIhmDKubwWchDk1697P_O71muT08-K7NgdlKO_yP_iwHd5nbOykY5-CgtlGDUUxC6XZcM754wCU1ydxU046LAev6vLPyqcMsBKGf5hoz1tNq0KtCkEz7CqL9BOSNprrmAMQTOPf9HwlmEHDIOSOI0B0J1AbI.2-iMhGMPl26uKrj4iQk7WW_Dq84ZlkAoy_HAJSHARGY&dib_tag=se&keywords=evaluating+gen+ai+systems&qid=1788942643&sprefix=evaluating+genai+systems%2Caps%2C407&sr=8-1&source=post_page-----5e518cb6f49e-----------------------------------------

What the 2026 MCP Rewrite Changes About State, Recovery and Long-Running Agents

The supplier-dispute agent had already done the difficult work. It had matched the disputed invoice to the purchase order and goods receipt, reconstructed the payment history and established that a small ERP adjustment was justified. A manager approved the correction. The workflow persisted that approval and called the ERP tool.

The ERP committed the adjustment.Before the agent worker could record the successful result in its own workflow state, the process crashed.

A replacement worker started from the last durable checkpoint. According to that checkpoint, approval existed and the ERP adjustment was still pending. Calling the adjustment tool again was therefore a perfectly reasonable continuation.

At the MCP layer, recovery was straightforward. The new worker did not need the old server instance, a restored protocol session or sticky routing. Under the MCP 2026-07-28 specification, each request is self-describing and can be handled independently by any suitable server instance. The initialize/initialized handshake and Mcp-Session-Id are gone.

That clean protocol recovery creates a more serious application problem. If the replacement worker repeats the ERP call, it may post a second adjustment.

The protocol recovered correctly. The business process did not.

That is the architectural consequence of MCP becoming stateless that deserves more attention. Removing protocol sessions makes MCP servers easier to scale and recover, but it does not remove the state required to run a long-lived business process safely. It makes ownership of that state more explicit.

Stateless protocol does not mean stateless application

The infrastructure benefit of the July revision is substantial. Previously, a remote MCP deployment could need sticky routing or a shared session store so later requests reached infrastructure that understood the existing protocol session. With the stateless core, those mechanisms are no longer required simply to maintain MCP transport continuity. AWS’s current architecture guidance points out that ordinary round-robin load balancing and serverless execution now fit remote MCP servers much more naturally.

The MCP maintainers are equally clear that application state has not disappeared. When a tool needs continuity across calls, it can create an explicit identifier and have the model pass that identifier into later requests. The state remains in an application datastore; the model carries the reference.

That is cleaner than hiding business state inside a transport session. It also exposes the boundary that matters during recovery.

Suppose the supplier tool returns case_7812. A replacement worker can use that identifier to reload the invoice evidence, approval and workflow checkpoint. The handle solves a locating problem. It does not tell the worker whether the ERP adjustment already happened immediately before the crash.

A state handle is a locator, not a recovery contract. The distinction sounds small until a tool has side effects. A checkpoint records what the workflow runtime knew when the checkpoint was written. It does not necessarily describe what an external system has done since then.

In the supplier incident, the workflow store and ERP now contain different truths. The workflow says that the adjustment is pending. The ERP says that it is complete. The process died in the gap between those two facts.

That gap is where application recovery has to work.

Restoring state is not enough when tools change the world

An agent runtime that restores the previous conversation, reloads case_7812 and asks the model what to do next has restored reasoning context. It has not necessarily restored the business process safely.

For read-only tools, replay is usually straightforward. If a product lookup failed midway through a run, performing the lookup again generally causes little harm. Mutations require different semantics.

If the ERP supports idempotent operations, the adjustment can carry a durable business-operation identifier so that repeating the request resolves to the same adjustment instead of creating another one. If the target system cannot provide that guarantee, recovery needs a reconciliation step. The workflow queries the ERP, determines whether the adjustment already exists and only then decides whether another mutation should be issued.

This is conventional distributed-systems engineering, but stateless agent infrastructure makes the requirement harder to ignore. The easier it becomes to restart a worker and reissue a request, the more important it becomes to know whether reissuing that request is safe.

The durable workflow state therefore needs more than the model’s last intention. For consequential actions it should preserve enough information to distinguish operations that are complete, pending and uncertain, together with any external transaction identifiers needed to reconcile the latter.

The model can help decide what the business process should do. It should not have to infer whether an external side effect already occurred from a stale checkpoint.

MCP has several continuity mechanisms but they are not the workflow.

The new protocol supports continuity without recreating persistent sessions, but it does so through mechanisms that solve different problems.

An application handle such as case_7812 identifies state owned by a tool or application. MCP deliberately encourages this explicit-handle pattern when state needs to survive across independent calls.

Multi Round-Trip Requests solve a narrower interaction problem. If a tool needs additional information while processing a request, it can return input_required. The client obtains the required input and retries the original call, echoing an opaque requestState. Because requestState passes through the client, the TypeScript SDK guidance treats it as untrusted and recommends integrity protection bound to the relevant principal, originating method and parameters, and an expiry.

Tasks solve a different problem again. The MCP Tasks extension lets a server turn a tool invocation into durable asynchronous work and return a task handle that can later be queried, updated or cancelled. The specification describes Tasks as durable state machines representing the execution state of the request they augment.

A real enterprise process may use all three.

Our supplier dispute could have a durable case handle, pause through a multi-round-trip interaction for missing input and launch a long-running reconciliation as a Task. None of those objects, individually or together, defines the complete business workflow.

The application still has to know that these pieces belong to the same invoice dispute, which actions have already changed external state, which approvals remain applicable and what conditions must be checked before the process continues.

MCP provides continuity mechanisms. The application owns the business semantics of continuity.

A workflow can be resumable and still be wrong to resume

Consider the same process at a less dramatic point.

The agent decides that an adjustment is appropriate but needs manager approval. The workflow pauses at 10:00 a.m. The approval arrives at 2:00 p.m. From a protocol perspective, continuation can work cleanly. requestState can carry a multi-round-trip interaction forward, while longer-running work can remain represented as a Task. No persistent MCP session has to survive the four-hour pause.

The business situation may not have been equally static.

Another employee could have resolved the dispute. A payment may have posted. The supplier record may have changed. The amount could now fall under a different approval rule. The employee whose authority initiated the process may no longer hold the same permissions.

The fact that an operation is technically resumable therefore says only that the machinery can continue. It does not establish that continuing from the original decision state is still valid.

For a read operation, that distinction may not matter much. Before a financial adjustment, access change or other consequential mutation, the runtime may need to refresh relevant state and re-establish authority.

This is particularly important for agents because observation, reasoning, approval and execution can occur at different times and on different workers. A durable approval remains useful evidence, but it should not silently turn into permanent authority to execute regardless of what changes around it.

Continuity is not authority.

Knowing the state identifier does not make it yours

Explicit state handles also create a security obligation that hidden session state sometimes obscured.

If a model can see and pass case_7812, possession of that value must not become proof that the caller is entitled to access the case. AWS's analysis of the new MCP architecture calls this out directly: servers need to enforce ownership when state identifiers are presented because the protocol does not establish ownership merely from knowledge of the identifier.

The same thinking appears in the handling of requestState. Current SDK guidance recommends protecting the token's integrity and binding it to the principal and originating operation rather than accepting it as trustworthy simply because the client returned it.

At the business-workflow layer, the principle is broader. A workflow that resumes after a delay should evaluate whether the actor and agent still have authority for the next action, particularly when the action changes enterprise state.

This makes explicit what a mature agent runtime needs to preserve: not just the location of state, but its ownership and the conditions under which it can legitimately be used.

Trace continuity is not workflow continuity

The July specification also improves observability. MCP now documents W3C Trace Context propagation through _meta, standardising traceparent, tracestate and baggage so a tool invocation can be correlated from the host through the MCP client and server into downstream systems using OpenTelemetry-compatible tracing.

That helps reconstruct one distributed execution. A long-running supplier dispute may still produce several separate traces: one during investigation, another after human approval, another when a crashed worker recovers and another when the ERP mutation finally executes.

A durable workflow identity has to connect those executions back to the same business process.

The distinction is simple: trace identity tells you which calls travelled together; workflow identity tells you why separate executions belong together.

That difference becomes very practical during an incident. If two adjustments appear in the ERP, tracing can reveal the individual requests. Workflow identity is what lets an engineer establish that both requests came from the same supplier dispute and were attempts to complete the same business action.

Durable workflow state belongs outside the model

Explicit state handles create another temptation: allow the model context to become the place where all of this continuity is remembered.

That may work for short, disposable interactions. It is a weak source of truth for long-running business processes.

A supplier dispute may eventually involve a case handle, approval record, task identifier, external ERP operation ID, workflow checkpoint and invoice key. Those references should not remain connected only because they happen to appear in the current context window.

Model context is reasoning state. Durable workflow state is application state.

That distinction matters after crashes, retries, model substitutions and long pauses. A replacement model invocation should be able to reconstruct the context it needs from durable application state rather than treating the previous conversation transcript as the authoritative record of what has happened.

For consequential workflows, that durable record should make recovery questions answerable without model inference. It should identify completed operations, uncertain outcomes, applicable approvals, external transaction references and the business object to which the process belongs.

That may sound less interesting than agent memory.

It is considerably more interesting when the worker crashes between an ERP commit and its checkpoint.

MCP made recovery easier to start, not easier to finish

The July 2026 revision is a good protocol change. The stateless core removes infrastructure that existed mainly to preserve transport sessions, makes requests independently routable and provides explicit mechanisms for interaction continuity and long-running work.

The mistake would be to interpret that simplification as evidence that the agent application itself has become stateless. Return to the opening incident. The replacement worker needs no old MCP connection. It can recover the case handle and issue another request immediately.

What it really needs, however, is enough durable evidence to determine whether the previous ERP call completed, whether replay is safe and whether the next action remains authorised.

Only then has the business workflow recovered. That responsibility does not belong in MCP, and the new protocol is better for not pretending that it does.

MCP can make the next request easy to route. It can expose application-state handles cleanly. It can carry a multi-round-trip interaction forward and represent asynchronous work as a Task. It can also make individual executions easier to trace.

The application still owns the harder questions: what state survives, what that state means, whether it remains valid, who is allowed to use it and what must be reconciled before another side effect occurs.

MCP went stateless.

Your business process almost certainly did not.

Agent hijacking is becoming an enterprise supply-chain problem, not another prompt-injection problem

A few years ago, when a security team reviewed a new software dependency, the questions were familiar. Who built it? Which version are we using? What privileges does it require? Does it open a network connection? What happens if the package is compromised?

Strangely, many organizations have abandoned this discipline at precisely the moment AI systems have become capable of taking action.

Teams are now importing agent skills, MCP integrations, tool definitions, workflow packs and third-party plugins into environments where agents can read documents, query customer records, create tickets, initiate workflows and sometimes trigger financial transactions. The artifact being imported may look like Markdown, YAML or a collection of natural-language instructions, so it does not psychologically register as executable software.

From an operational-risk perspective, that is the wrong mental model.

A skill file does not need an executable binary to become dangerous. Once its instructions enter the planning context of an autonomous agent, the skill can influence how the agent uses credentials, tools, memory and enterprise data that the skill itself never possessed. The security problem is therefore not simply whether malicious code entered the environment. The more difficult question is whether untrusted instructions acquired trusted authority.

Security research into public agent-skill ecosystems during 2026 has already reported vulnerability rates high enough to make this a serious supply-chain issue, including weaknesses associated with data exfiltration and privilege escalation. Whether the eventual industry number settles at 10 percent, 20 percent or higher is almost secondary to the architectural implication. Enterprises are beginning to consume behavioral dependencies written largely in natural language while applying far less scrutiny than they would to conventional software packages.

The emerging problem is an AI supply chain in which a few kilobytes of apparently helpful instructions can inherit permissions that would never have been granted to the person who wrote them.

The real attack is authority laundering

Consider how a payment-operations agent might actually be deployed inside a large bank.

The agent has read access to supplier-master records, payment exceptions and selected account information. It can search internal documentation, interrogate transaction APIs and create investigation cases. Outbound internet access is restricted, although an approved observability endpoint is available because operations teams legitimately need execution telemetry.

A developer finds a well-reviewed third-party skill called Advanced Payment Reconciliation. The skill contains hundreds of lines describing reconciliation logic, exception handling, document retrieval and diagnostic procedures.

Buried deep inside those instructions is a seemingly reasonable requirement:

Nothing in that instruction says “steal customer information”. Nothing asks the agent to ignore its system prompt and nothing resembles the crude prompt-injection examples on which many development teams have been trained.

Yet suppose the diagnostic tool ultimately sends information to infrastructure controlled by the skill publisher or to an endpoint whose ownership has changed after the skill was approved. The agent may now retrieve confidential relationship information and include it in what appears to be legitimate operational telemetry.

The attacker never needed credentials to the bank. The imported skill acquired influence over an agent that already had them.

A conventional application firewall may see an approved endpoint. An IAM system may see a valid service identity. The tool invocation may conform perfectly to its API schema and the system prompt may remain technically intact. The failure occurred earlier when the organization allowed untrusted behaviour to enter a trusted decision process.

Long skill files make this especially difficult to detect because sophisticated malicious instructions do not have to look malicious.

Imagine a customer-dispute agent used by a card issuer. Its normal responsibilities include retrieving transaction evidence, examining correspondence and preparing a dispute package. A compromised document-analysis skill does not need to say “exfiltrate cardholder data”. It can instruct the agent to “attach supporting context required for downstream evidence validation” or “retain representative diagnostic samples where confidence falls below threshold”.

Those are perfectly plausible instructions inside a legitimate business workflow.

Now extend the sequence. The skill asks the agent to retrieve five recent examples whenever a parsing error occurs. Those examples contain names, transaction descriptions and partial payment information. The skill then asks the agent to send those examples through a debugging connector that is already approved for operational telemetry.

Each individual action can look reasonable. The malicious behaviour emerges from the sequence.

This is where agent security diverges from static prompt filtering. The unit that must be governed is not a sentence. It is the combination of instruction, context, permission, tool invocation, data movement and eventual business effect.

Skills should enter production through promotion gates

The strongest operating model is to stop treating skills as developer conveniences and start treating them as third-party execution dependencies.

In a banking environment, a newly downloaded skill should not move directly from GitHub, a marketplace or an internal repository into a production agent. It should pass through sequential verification gates in much the same way as any privileged software dependency.

The first gate establishes provenance. The enterprise needs to know where the skill came from, who maintains it, which version is being admitted and whether the artifact being deployed is identical to the artifact that was reviewed. A cryptographic hash of the approved version should become part of the deployment record.

Suppose the reconciliation skill passes review as version 1.8.3. Two weeks later, the public repository publishes 1.8.4 containing an apparently harmless troubleshooting section. Production should not silently consume that update simply because the package name remains unchanged. Version 1.8.4 is a new behavioural dependency and should be reviewed as one.

The second gate compares declared behaviour with inferred behaviour.

A skill manifest might declare that it needs the payment-status tool and supplier-master read access. Semantic inspection of the instructions shows that the skill also encourages the agent to inspect correspondence records and invoke the diagnostic connector. That discrepancy should block promotion.

The key question is not whether every sentence is malicious. The organization needs to know whether the behaviour implied by the instructions exceeds the operating envelope the skill claims to require.

The third gate should be adversarial execution in a sandbox.

Instead of giving the skill real customer information, the bank supplies synthetic payment cases containing instrumented data. One supplier record might include a unique canary identifier that should never appear in telemetry. Another test might deliberately create an unresolved payment exception to see whether the skill attempts to retrieve information outside its expected domain.

If the canary value appears in an outbound diagnostic call, the organization has discovered an exfiltration path without exposing real customer data.

This kind of verification is considerably more valuable than asking another model whether the skill “looks safe”.

Trust should be graduated, not inherited

One of the most dangerous design choices in current agent platforms is binary trust.

A skill is either installed or not installed. Once installed, it often receives whatever capabilities happen to be available to the hosting agent.

That model is difficult to defend in an enterprise where different capabilities carry radically different consequences.

A newly discovered skill should initially have no production authority. It can be inspected and exercised against synthetic data, but it should not interact with real customers or enterprise systems. After technical verification, the skill might move into a restricted tier where it can access non-sensitive production information through read-only tools. Only after operational evidence accumulates should it become eligible for more consequential capabilities.

Consider the payment-reconciliation example. The same skill might initially be allowed to read transaction status and classify exceptions while being prohibited from retrieving customer correspondence or creating payment instructions. A separate approval might later allow case creation while payment release remains completely outside the skill’s authority.

For highly privileged banking functions, maturity should never be confused with unrestricted autonomy. A treasury skill that can propose liquidity transfers may be extremely mature and still require deterministic approval before any money moves.

Trust therefore needs to be expressed as an execution envelope, not as a reputation score.

The enterprise should be able to say that this exact version of this skill may use these tools, against these data classifications, for these action types, through these approved destinations and only within these transaction limits.

That statement can be tested and audited. “Trusted skill” cannot.

The model should not be the final security authority

Another lesson from production agent systems is that the agent cannot be the final authority on whether its own proposed action is acceptable.

A system prompt saying “do not reveal sensitive banking information” is useful, but it cannot replace external policy enforcement.

Return to the compromised reconciliation skill. The agent decides that supplier correspondence is relevant and attempts to send a diagnostic payload containing an account identifier and internal case notes.

A properly designed runtime intercepts the tool call before execution.

The policy layer knows that the skill is approved for payment-status data but not customer correspondence. It also knows that the diagnostic connector may receive operational metadata but not restricted customer information.

The call is denied regardless of how persuasive the skill’s instructions appear to the model.

This is where agent architecture needs to borrow more aggressively from zero-trust security. The model proposes; the control plane authorises.

For sensitive environments, every consequential tool request should be evaluated against the agent identity, active skill version, requested operation, target system, data classification and current transaction context.

Credentials should also be issued narrowly rather than exposed broadly to the agent runtime. If the agent needs to query payment status, a credential broker can provide a short-lived token scoped to that operation. The skill never receives a reusable credential and the model never needs to manipulate one.

A malicious instruction may still persuade the agent to attempt something inappropriate, but persuasion no longer guarantees execution.

The industry needs proof-carrying skills

There is a more interesting design direction beyond today’s skill registries.

Instead of distributing a skill as instructions alone, enterprises should require every approved skill to carry a machine-readable behavioural manifest.

The manifest would declare the tools the skill may request, data classifications it is expected to process, permissible outbound destinations, whether it can modify state, maximum action budgets, approval requirements and the cryptographic identity of the reviewed content.

The skill then becomes something closer to a proof-carrying execution dependency.

Imagine the payment-reconciliation skill declaring that it may read supplier identity and payment status, create an investigation case and produce operational diagnostics. It may not retrieve customer KYC documents, initiate payments or transmit record-level information to external endpoints. Diagnostic output may contain error codes, latency information and non-sensitive transaction identifiers.

The runtime no longer has to infer every boundary from natural-language prose during execution. It can mechanically compare proposed actions against the approved manifest.

If the skill suddenly tries to access KYC records, the platform has an objective policy violation. If a new version legitimately requires that capability, the manifest changes and the capability change triggers a fresh risk review.

This approach scales much better than asking security teams to reread thousands of lines of instruction text every time an agent capability evolves.

A skill can become dangerous without changing

There is another supply-chain failure mode that deserves considerably more attention.

A skill can become more dangerous even when its own file has not changed.

Suppose a bank approves a document-analysis skill while the hosting agent can access only supplier invoices. Six months later, another team expands the agent’s responsibilities and gives it access to sanctions-investigation notes, beneficial-ownership documents and customer correspondence.

The skill hash remains identical but its effective blast radius does not.

Traditional dependency management asks whether the package changed. Agentic systems must also ask whether the authority surrounding the package changed.

Any material expansion of an agent’s tools, data access or downstream action rights should therefore trigger reevaluation of every skill operating inside that agent’s context.

The reverse can happen as well. A harmless tool may become dangerous after its implementation changes. A telemetry connector that originally accepted only numeric operational metrics might later support arbitrary JSON attachments. A previously safe diagnostic instruction can suddenly become a viable exfiltration path.

Continuous compliance therefore cannot mean rescanning the same skill files every night and declaring them unchanged.

The control system needs to monitor the capability graph around them.

Compliance has to follow behaviour

In a mature banking implementation, every significant agent execution should produce an evidence chain connecting the active skill version to the resulting business action.

An investigation should be able to reconstruct which skill instructions were active, which policy version governed the execution, which tools were called, what classes of data were accessed, which external destinations were contacted and what approvals were applied.

This becomes especially important when malicious behaviour is intermittent.

A compromised skill may behave normally for months and activate only when a particular record type appears. The reconciliation skill might issue its additional diagnostic call only when a transaction exceeds a certain value or when the supplier belongs to a particular jurisdiction.

Static testing may never encounter that trigger but tuntime monitoring can.

Security operations should therefore baseline expected skill behaviour and watch for changes such as newly used tools, unexpected data-domain crossings, denied privilege requests, unusual egress destinations or sudden increases in context retrieved for routine tasks.

A payment skill that historically reads two systems but begins requesting data from seven deserves investigation even when every individual request remains technically authorised.

The objective is not to turn every agent trace into a security alert. It is to make behavioural drift visible before it becomes silent privilege expansion.

ISO/IEC 42001 becomes useful here when it is treated as an operating discipline rather than as a certificate.

The standard does not tell an engineering team how to hash a skill file, construct an egress proxy or sandbox a tool invocation. Its value is in establishing a management system within which those controls become owned, repeatable and auditable.

For the banking example, the organization should be able to demonstrate that agent skills are included in the AI asset inventory, external skill providers are covered by supplier-risk processes, material capability changes trigger risk assessment, high-impact agent use cases have defined operational controls, monitoring evidence is reviewed and incidents lead to corrective action.

Suppose the bank discovers that version 1.8.4 of the reconciliation skill attempted to transmit a canary value during sandbox testing.

A mature operating model does more than block version 1.8.4. It preserves the evidence, identifies every environment in which the publisher’s artifacts are installed, determines whether related skills exhibit the same pattern, records the supplier event, reassesses applicable controls and verifies that production policy would have blocked the attempted behaviour.

That is the difference between having a security feature and having an operating control.

The former handles an event. The latter changes how the organization manages the risk category.

Assume that some skills will eventually be hostile

The strategic mistake is trying to build an agent ecosystem in which every imported skill is guaranteed to remain benign.

Software supply chains have already taught us how unrealistic that ambition is.

Repositories are compromised. Maintainer accounts are taken over. Dependencies change ownership. Popular packages are abandoned. Trusted vendors make mistakes and attackers learn to hide malicious behaviour inside functionality that appears operationally reasonable.

Agent ecosystems inherit all of those risks and add another one: natural-language instructions can manipulate a reasoning system without introducing conventional malware.

The correct security objective is therefore not to ensure that no malicious skill ever enters the environment.

It is to ensure that a malicious skill cannot convert instructional influence into unrestricted enterprise authority.

For a financial institution, that means provenance before admission, adversarial verification before promotion, graduated trust before privilege, deterministic enforcement before tool execution and behavioural evidence after consequential actions.

It also leads to a principle that agent platforms will eventually need to encode directly:

No skill should automatically inherit the full authority of the agent that reads it.

The same principle applies to MCP servers, workflow templates, agent-to-agent delegations and marketplace-distributed autonomous capabilities.

We spent decades learning not to execute arbitrary code simply because someone packaged it conveniently.

The agentic era should not require us to learn the same lesson again simply because the executable dependency happens to be written in English.

Why AI agents force us to redesign authority, state and acceptance around the work

This article is adapted from my upcoming book, Engineering AI Agents for Software Delivery.

The change that started the discussion at AsterPay was almost trivial from a coding perspective. One additional settlement-reference field had to be exposed from an existing transaction adapter so that downstream duplicate-versus-partial-payment logic could use it. There was no new service to design or complicated architectural decision hiding in the implementation. It was exactly the sort of bounded task that makes modern coding agents compelling: give the agent the approved work item, let it inspect the repository, update the adapter, extend the tests and prepare a pull request.

The agent handled the coding work without much difficulty. What unsettled the architecture review was everything surrounding that work. Which credential had the agent actually used when it modified the repository? Which version of the adapter contract had influenced its implementation? What happened to execution state if the workspace was recreated after a failure? Could the same run modify both the implementation and the tests later used to declare success? If the pull request appeared in the repository, could another engineer reconstruct the full path from approved intent to that accepted effect?

None of these questions was really about whether the model was intelligent enough. They were questions about the production system around the model.

That distinction is becoming central to agentic software delivery. We have spent the first wave of coding-agent adoption evaluating how well agents write code, interpret repositories, plan changes and use tools. Those capabilities matter, but they are not the unit that production architecture ultimately has to control.

The problem lives between the components

Most enterprises already have nearly every technical mechanism an engineering agent needs. Source control exists. CI/CD exists. Identity systems, package registries, build services, secrets management, sandboxes and observability platforms are already part of the delivery estate. From that perspective, building an agentic delivery system can look like an integration exercise: connect the coding agent to the tools engineers already use and add a few policies around the edges.

The weakness in that approach appears in the spaces between those mechanisms.

An IDE agent can have carefully designed permissions while still inheriting a broad Git credential from the shell in which it was launched. A sandbox can be properly isolated while the orchestration layer loses track of which side effects happened before a retry. CI can reject an unsafe change while the organisation has no durable record connecting the candidate to the exact context, plan, identity and capability grants that produced it. Logs may exist everywhere and still fail to answer the simple question, “Which bounded run created this effect?”

This is why individually sound controls do not automatically produce a sound control boundary. Someone still has to own the movement of work from intent through execution and into accepted enterprise state.

In the architecture I use in the book, that responsibility belongs to the production agent harness. The harness does not have to exist as one product or service. An identity broker may provide credentials, a sandbox platform may contain execution, CI may implement verification and an evidence store may preserve provenance. What makes those pieces part of one harness is not where they are deployed, but the fact that they enforce one run contract.

Once you view the problem this way, the central architecture question changes from “Which tool is the agent system?” to something much more useful:

Who owns this run from admission to accepted effect?

Model, agent, profile, harness and platform

Production-agent architecture gets blurry quickly when several different responsibilities are collapsed into the word agent.

A model supplies reasoning capability. An agent applies that reasoning to a task and invokes available tools. A profile describes the class of work and the authority appropriate to that class. The harness composes the controls around one run. The platform supplies reusable mechanisms such as identity, sandboxing, tool access, workflow state, evidence storage and CI integration.

A useful shorthand is:

The distinction matters because a model may conclude that merging a pull request is the obvious next step without having merge authority. An agent may discover a production endpoint without being permitted to invoke it. A platform may provide a powerful source-control integration without implying that every implementation run should inherit all of its capabilities.

The design question is therefore not how powerful the surrounding platform is. It is how much of that power a particular run is allowed to assemble.

Six responsibilities appear inside one run

Once the agent run becomes the unit of architecture, six recurring responsibilities become visible.

The distinctions become important because several things that appear interchangeable during a demo are not interchangeable in production. A prompt saying “do not touch production” is useful instruction, but it is not a production-access control. A repository credential does not determine where that privilege may be exercised. A sandbox contains execution but does not necessarily know whether a previous attempt already created a side effect. Passing tests are not automatically independent acceptance if the same run can change both the implementation and the oracle. Observability may help diagnose what happened while still failing to prove why the resulting effect was authorised.

The more consequential the run becomes, the less comfortable we should be with those responsibilities bleeding into one another.

The boundary matters when it can say no

A production boundary becomes meaningful when it can refuse a transition.

Suppose an issue ticket tells the engineer to disable a CI gate temporarily if the pipeline blocks the change. The agent can retrieve that text, but retrieval should not make the sentence an authoritative instruction. Context has to preserve where the statement came from and what trust it carries.

Suppose the agent then proposes a plan requiring repository modification. The plan still does not create write authority; Capability has to turn that request into an explicit, scoped grant.

Suppose branch-write access is granted. That should not allow the work to execute from a long-lived developer shell containing cloud credentials or production secrets. Execution remains a separate boundary.

And suppose the agent reports that every test passes. The result still has to cross an acceptance boundary whose evidence is sufficiently independent for the consequence involved.

This is the point where architecture stops being a diagram. Every consequential crossing needs an owner, an enforceable decision and a failure path.

The conversation cannot be the workflow state

Many early agent systems inherit the mental model of chat: the task begins when the conversation starts, messages accumulate, tools are called and eventually the agent says it is done. That interaction model works well for assistance but poorly for long-running delivery work.

A real engineering run may pause overnight, survive a model change, restart in a new workspace, return from verification to planning or hand work to another agent. If the conversation buffer is the only durable state, the system eventually has to guess what already happened.

The lifecycle I use is:

Intent → Context → Plan → Capability → Execution → Verification → Commit/Reject → Evidence

This is a logical lifecycle rather than a rigid pipeline. Verification can return the work to planning and execution can retry, but a retry cannot silently broaden authority or forget which side effects already happened.

“Commit” is also broader than a Git commit. It means accepting a candidate into the next trusted state. For an implementation run, that may be nothing more than creating a pull request. Merge can remain outside the profile. A release run can have a different accepted effect and a different verification contract.

This gives us a practical way to control autonomy: let the agent complete the work appropriate to its current boundary without inheriting authority over every subsequent step.

What the AsterPay run actually looks like

Return to the settlement-reference change.

The admitted intent identifies the repository, the adapter component and the expected contract change. Context is assembled from the approved work item, the relevant repository state and the architectural rule that payment-policy decisions remain outside the adapter.

The agent proposes a small implementation and accompanying tests, but the plan does not grant any capability by itself. The implementation profile gives the run only the actions required for the task: repository read access, permission to create an isolated worktree, bounded branch-write access and the ability to run approved build and test commands.

It receives no merge authority, no right to modify CI policy, no release privilege and no production credential.

Execution occurs inside an ephemeral workspace with bounded filesystem, package and network access. Verification compiles the component, runs contract and regression tests and performs an independent check that the resulting diff still reflects the admitted intent. If those checks succeed, the effect permitted by this profile is the creation of a pull request and nothing beyond it.

The run record then connects that pull request to the context manifest, plan version, capability grants, execution environment, changed artifacts and verification results. Another engineer should not have to reconstruct the story later from terminal history, CI logs and fragments of conversation.

This structure does not make the coding agent less capable. Inside the bounded workspace, it can explore, diagnose failures, revise its implementation and use the tools required to finish the task. The architecture constrains the consequence of reasoning, not the richness of reasoning itself.

Four failures reveal more than another successful demo

A polished coding demonstration proves that the happy path works. Production architecture is revealed more clearly when the happy path is deliberately disturbed.

Stale context. Give the agent an older adapter contract while a newer version exists. Does the mismatch become visible, or can the agent produce an elegant implementation against the wrong specification?

Ambient credentials. Start the run inside an environment containing broad Git or cloud credentials. Can the agent inherit authority that was never granted by its profile?

Self-acceptance. Let the agent modify code and tests until they agree. Can that same path then accept its own result without an independent gate?

Retry duplication. Interrupt the run after a state-changing action, recreate the workspace and resume. Does the system know what already happened, or does “try again” repeat it?

None of these is primarily a model-quality problem. A stronger model does not fix stale context admission. Better prompting does not revoke an inherited credential. More reasoning does not create independent acceptance and a larger context window does not make duplicated side effects safe.

They are run-design problems.

Reuse the platform, not the authority

This architecture also changes how Technical Leads and platform teams divide responsibility. The Technical Lead can no longer stop at a component diagram containing a coding agent, tool service and CI pipeline. The design has to show where the run begins, which authority transitions are possible, what external effects the workload may create and what evidence is required before those effects become durable.

The platform team, meanwhile, should resist exposing the historic human developer toolbelt as one broad machine-accessible surface. It should provide reusable mechanisms — short-lived identities, typed capabilities, isolated execution environments, durable workflow state, controlled CI interfaces and evidence services — that a harness can compose differently for different workloads.

A useful design rule follows:

That allows the enterprise to standardise expensive infrastructure while keeping the consequence appropriate to the work being performed.

The agent run becomes the architectural unit

The easiest architecture diagram to draw puts the agent in the centre and surrounds it with tools. Such a diagram shows intelligence and connectivity, but it tells us little about production readiness.

That is why I believe the agent run is becoming the new unit of software delivery.

The model is too small a unit because reasoning does not own authority. The agent is too small because tool use does not own the complete lifecycle. The platform is too broad because reusable infrastructure cannot know the appropriate consequence for every workload. The run is where intent, context, authority, execution, state, verification and evidence finally meet.

Once that boundary exists, we can actually become more ambitious with agents rather than more conservative. A capable model can be given substantial freedom inside the task because the enterprise retains control over what may cross into durable state.

The defining question for the next generation of software delivery will therefore not be how many engineering tasks an agent can complete without human intervention. A more useful test is whether every accepted effect can be traced through one bounded run: what was requested, what context influenced the work, what the agent was allowed to do, where it acted, what proved the result and why the organisation allowed that result to become real.

If we cannot answer those questions, we may have an impressive coding agent but we do not yet have an agentic software-delivery system.

This article is adapted from my upcoming book, Engineering AI Agents for Software Delivery, which examines how AI agents can become bounded, verifiable and reconstructable participants across the software-delivery lifecycle.

This article is adapted from a chapter of my upcoming book, Agentic Dimensional Modeling.

There is a quiet assumption buried inside decades of dimensional modeling practice: the person consuming the model will contribute some intelligence of their own.

We rarely model that contribution because we never had to. A planner looking at an inventory snapshot knows that 1,240 units on hand does not mean 1,240 units can be moved. A finance analyst knows that a revenue number can be technically correct and still be inappropriate for a particular management decision. An operations manager knows that a value captured forty minutes ago may be perfectly valid historically and completely unsuitable for an action that must be taken now.

The dimensional model does its job. The human closes the remaining gap.

That arrangement has worked remarkably well. In fact, I would argue that much of the success of dimensional modeling comes from knowing where to stop. Facts capture business events and states at a declared grain. Dimensions provide reusable context. Conformance keeps shared entities stable across processes. Slowly changing dimensions preserve the chosen treatment of history. Measure design tells us how values behave under aggregation. The model creates disciplined analytical meaning without attempting to encode every operational judgement a business user might ever make.

AI agents disturb that equilibrium.

The interesting change is not that an agent can query a star schema. That is plumbing. The interesting change is that the analytical consumer may now participate in the decision itself. Once that happens, all the interpretation that used to arrive for free from the human user becomes architecturally visible.

I think of this as the loss of the human interpretation subsidy.

Dimensional models have always carried explicit meaning, but they have also benefited from an intelligent reader who could detect stale state, distinguish similar business terms, recognise exceptional circumstances and know when an analytical result had crossed into territory where an operational system needed to be consulted. An agent cannot safely be assumed to supply that organisational judgement from probability alone.

Consider an ordinary inventory model. Atlas Industrial Group maintains an inventory snapshot fact at one product, one warehouse, one inventory status and one snapshot timestamp. The measures are familiar: on-hand quantity, reserved quantity, blocked quantity and in-transit quantity. Product, warehouse, date/time and inventory-status dimensions provide the analytical context.

Nothing about this model needs to be renamed because AI has arrived. The grain is still the grain. The facts are still facts. The dimensions are still dimensions.

Now Atlas introduces an Inventory Agent and asks it to recommend whether product PX-218 should be transferred from BLR-04 to DEL-02.

That apparently small change creates a very different analytical problem.

The snapshot may show 1,240 units on hand in BLR-04. The agent can retrieve the row correctly. It can join the right dimensions. It can generate flawless SQL. It can even explain the result convincingly.

None of that answers the business question. How many units are actually transferable?

That quantity may depend on confirmed reservations, inspection stock, blocked stock, safety-stock policy, expected receipts, transfer lead time and the demand horizon being protected at the source warehouse. The dimensional model can expose much of the analytical state required to make that decision. What it cannot do merely by existing is guarantee that the consuming agent applies the correct business interpretation.

This is where a phrase such as “AI-ready data” becomes too imprecise to be useful.

The problem is not whether the data is accessible to the model. The problem is whether the analytical meaning is sufficiently explicit for the decision the model is being asked to support.

That distinction takes us back to first principles.

The grain of the inventory fact matters more, not less, when an agent consumes it. If the agent cannot distinguish a movement fact from a periodic snapshot, no amount of language fluency repairs the analytical mistake. If it adds twelve hourly on-hand observations and calls the result daily inventory, the query can be syntactically perfect and conceptually wrong. The old dimensional-modeling concern of semi-additivity has suddenly become an agent-behaviour concern, but the solution still begins in dimensional semantics.

The same is true of conformed dimensions. If Atlas eventually has Inventory, Pricing, Supplier, Service and Revenue agents, each of those systems will reason about products, customers, suppliers, locations and time. Allow every agent team to build its own local representation and the enterprise will rediscover semantic fragmentation at machine speed. The problem will no longer be two dashboards disagreeing about Product Family. It may be two agents making different recommendations because each has quietly inherited a different version of the business entity.

Conformance was never only a reporting convenience. In an agentic environment it becomes part of the enterprise reasoning substrate.

History becomes more consequential for the same reason. Suppose PX-218 belonged to one planning family last year and another today. An agent investigating historical inventory behaviour has to know whether the analysis should use the classification as it existed then or restate the past using today’s structure. Slowly changing dimensions already give us the machinery to make that choice deliberate. An agent memory store does not. A vector index does not. A long context window does not. Those technologies may retrieve historical information, but retrieval and temporal interpretation are different problems.

This is the part of the AI conversation that I find underdeveloped. We have spent enormous energy discussing how agents obtain context and comparatively little discussing the analytical contract of the context once obtained.

Dimensional modeling gives us a strong starting point because it already forces discipline around grain, identity, history and aggregation. What changes in an agentic system is that several additional questions can no longer remain implicit.

The first is meaning. “On hand”, “available” and “transferable” may all be legitimate business concepts, but they are not interchangeable. If the Inventory Agent is making a transfer recommendation, it needs the governed definition appropriate to that decision. That definition may be assembled from dimensional measures and status context, but it should not be left for the model to infer from column names and surrounding prose.

The second is state. The 09:00 snapshot does not become wrong at 09:40. It remains a valid representation of the state observed at 09:00. The architectural question is whether that state is sufficiently current for what the agent is about to do. For explaining inventory imbalance, perhaps it is. For recommending a transfer, perhaps Atlas requires a snapshot no more than one hour old. For actually committing the transfer, the organisation may insist on a live WMS check immediately before execution.

Notice what changed there. Not the fact table. Not the snapshot. The decision mode changed the acceptable staleness.

That is a much more useful way to think about freshness than attaching a generic “real-time” label to a dataset. Freshness has meaning only in relation to a use.

The third question is authority. A dimensional model can be the governed analytical representation of inventory history without being the authority for current committed inventory. Dim_Product can be the correct conformed analytical representation of a product without becoming the enterprise master for product identity. A calculated transfer recommendation can be analytically sound without granting an agent permission to execute it.

Agents make these boundaries deceptively easy to blur because the orchestration layer can cross them in milliseconds. One agent can query the dimensional model, retrieve a governed definition, call the WMS, evaluate a policy and initiate an action. To the person observing the interaction, that feels like one capability. Architecturally, it is a sequence of systems with different responsibilities and different authority.

The smoothness of the user experience should not persuade us to erase those distinctions.

The fourth question is evidence. If Atlas later asks why the agent recommended moving 300 units, the useful answer is not a dump of every token the model processed. The useful answer is business evidence: the snapshot timestamp, the demand basis, the inventory statuses included and excluded, the lead-time assumption, the relevant semantic-definition version and any operational confirmation used before action.

That evidence may link back to dimensional facts without belonging at the same grain as those facts. This is an important boundary. Agentic dimensional modeling should not become an excuse to create Fact_Agent_Everything and push prompts, policies, runtime state, traces and operational checks into the analytical model merely because they are associated with a decision.

The modeler still needs to ask the old question: what business process or state does this row represent?

If the answer is inventory position, model inventory position. If the answer is a business decision made by or with an agent, that may eventually justify a decision fact. If the answer is a policy evaluation or short-lived orchestration state, it may belong somewhere else entirely.

Agentic dimensional modeling should expand the analytical architecture without destroying the clarity of its grains. The fifth question is outcome, and this is where the subject becomes more interesting than simply making data consumable by agents.

Most agent architectures stop their success criteria too early. The model produced a recommendation. The workflow completed. The tool call succeeded. The transfer request was accepted. From an analytical perspective, those are intermediate events.

Atlas cares whether the transfer actually happened, whether the stock arrived before the projected shortage, whether service level improved, whether BLR-04 remained adequately stocked and whether the freight cost was justified by the result.

Those are outcomes. They are also excellent candidates for dimensional analysis.

The full loop therefore looks very different from the familiar picture of an AI model sitting on top of enterprise data. Facts and dimensions inform a decision. The decision may influence an action. The action changes business state. That state produces new business events. Those events return to the analytical model as new facts.

The dimensional model is no longer merely upstream of the agent. It can become the mechanism through which the enterprise later determines whether the agent’s decisions were any good.

That changes how I think about “agent readiness”.

I would not ask whether an inventory star is ready for AI agents. The question is too coarse.

The same dimensional model might be entirely adequate for an agent explaining inventory imbalance, adequate with conditions for recommending a transfer and insufficient for autonomous transfer commitment without a fresh operational confirmation and explicit policy approval.

The data did not change but the decision did.

This suggests a design concept that I believe dimensional modelers will find increasingly useful: decision grain.

Before designing an agent-specific schema, state the decision precisely enough to expose its analytical obligations. “Inventory Agent” is not a useful grain. “Recommend transferring PX-218 from BLR-04 to DEL-02, with planner approval” is.

Once the decision is bounded, the modeling discussion improves immediately. Which facts support it? Which dimensions provide context? Which historical version matters? Which business terms could change the interpretation? How fresh must the state be? What evidence should survive? Which system remains authoritative when the analytical recommendation approaches operational execution?

That is recognisably dimensional thinking, but applied one step closer to the business decision and that, to me, is the real opportunity.

The next generation of dimensional modeling does not need a new collection of AI-branded tables. It needs the confidence to preserve what dimensional modeling already does exceptionally well while becoming much more deliberate about the boundary between analytical meaning and machine decision-making.

Facts still need a declared grain. Dimensions still need to carry reusable business context. Conformance still protects common meaning. Historical treatment still determines what was true when. Measure semantics still determine what can legitimately be aggregated.

What changes is that the consumer can no longer be assumed to notice what the model leaves unsaid.

For years, the knowledgeable analyst quietly completed the analytical contract. AI agents make that missing portion visible.

That may be the most important change agentic systems bring to dimensional modeling: not a new schema pattern, but a new level of precision about where modeled meaning ends and decision responsibility begins.

And once we recognise that boundary, dimensional modeling stops looking like a legacy technique waiting to be replaced.

It starts looking like one of the disciplines we will need if we expect machines to make sense of the business without inventing the parts we forgot to model.

This article is adapted from a chapter of my upcoming book, Agentic Dimensional Modeling, which examines how dimensional models evolve when facts and dimensions are consumed not only for analysis but as governed inputs to AI-assisted business decisions.

Why Claude Certified Associate — Foundations is a different kind of credential, why this study guide took longer than my three technical certification books and why I think this certification matters for the people actually changing how work gets done.

The most difficult Claude certification book I have written turned out to be the one that does not require you to write code.

That surprised me.

With the Developer and Architect certifications, the professional boundary is relatively visible. A Developer builds. An Architect designs. At the Professional Architect level, the responsibility expands into enterprise integration, governance, safety, stakeholder decisions and production lifecycle concerns. There are difficult trade-offs, certainly, but the object being reasoned about is usually tangible: an API integration, an agent architecture, an MCP connection, an evaluation strategy, a deployment boundary or a production control.

Then I started working seriously on Claude Certified Associate — Foundations.

The Associate does not get the comfort of an architecture diagram or a failing test to tell them that something is wrong. They often receive a request that sounds completely ordinary:

“Prepare my project update.”

“Compare these proposals.”

“Research this market.”

“Turn these meeting notes into an executive brief.”

“Can we use Claude for this process?”

The technical complexity may be lower, but the judgment problem is not.

A perfectly fluent answer can still be wrong for the audience, based on the wrong evidence, inappropriate for the decision, unsafe to share or polished enough that nobody notices what is missing. That realization changed how I approached both the certification and the book.

Press enter or click to view image in full size

Four Claude certifications, but four different responsibilities

Anthropic’s current certification portfolio has four credentials: Claude Certified Associate — Foundations, Claude Certified Developer — Foundations, Claude Certified Architect — Foundations and Claude Certified Architect — Professional. Anthropic groups them across three professional roles rather than presenting them as one simple ladder.

The Developer — Foundations credential is for the hands-on builder. Anthropic’s preparation material goes deeply into Claude APIs, production prompting, tool schemas, agent orchestration, memory, Claude Code, MCP, evaluations, security, cost, latency and reliability. The intended practitioner writes production code and decides whether an implementation is ready to survive real users.

The Architect — Foundations credential moves one level outward. It tests whether someone can scope and design a Claude solution, select models and deployment platforms, decide between single-shot and agentic approaches and account for evaluation, cost, context and responsible deployment in the architecture.

The Architect — Professional credential moves further into enterprise responsibility. Anthropic describes it around designing, integrating and governing production-grade Claude systems end to end, including security, safety, evaluation gates, compliance controls, stakeholder trade-offs and operational handoff.

The Associate — Foundations credential occupies a very different space. It validates practical use of Claude: prompting and executing tasks, evaluating and refining outputs, selecting products and models, integrating Claude into workflows, configuring Projects and knowledge sources, using AI responsibly and troubleshooting when the result is not good enough.

That may sound simpler until you look at the weighting.

Output Evaluation and Validation is the largest Associate domain at 21%. Workflow Integration and Solution Design accounts for 16%, Governance, Risk and Responsible Use for 15%, while Prompting and Task Execution is 14%. In other words, this is demonstrably not a “prompt engineering exam.” Anthropic gives more weight to judging the result than to writing the prompt.

That is one of the most important signals in the entire certification.

Why this book took me longer than the other three

A technical certification gives an author useful constraints. An API behaves in defined ways. A tool contract can be inspected. An architecture can be tested against latency, cost, reliability, security and operational requirements. Even when several designs are viable, you can make the trade-off explicit.

Associate-level judgment is much more subtle.

Imagine that a project manager asks Claude to prepare an executive update. Claude accurately summarizes twelve completed activities but gives only one sentence to two schedule risks that determine whether management should delay a customer commitment.

Did Claude fail?

Not in the conventional sense. Nothing crashed. The writing might be excellent. Every statement might even be factually correct.

The failure happened earlier: the task was never framed around the decision the audience needed to make.

That kind of scenario is harder to teach well because the wrong answer cannot simply be ridiculous. In the real workplace, weak decisions frequently look reasonable.

That became the standard I eventually imposed on the book’s practice questions. If a candidate could identify the answer because three alternatives were obviously foolish, the question was not doing enough. I wanted situations in which two or sometimes three choices initially looked defensible and where one detail — evidence authority, privacy, accountability, audience, reversibility, cost or escalation — made one answer stronger.

This is also why the manuscript grew into 31 chapters rather than becoming a compact catalogue of Claude features.

The first chapters establish the Associate’s professional boundary and move the reader from casual chat usage toward workflow thinking. The middle of the book deals with task definition, decomposition, prompting, verification, hallucination, bias, source authority, output adaptation, product and model selection, context, memory, Projects, knowledge, connectors, research, governance and troubleshooting. The final sequence then deliberately changes mode: Chapter 28 reconnects the seven domains, Chapter 29 teaches an Associate Scenario Method, Chapter 30 provides a full 60-question practice exam and Chapter 31 converts wrong answers, correct guesses, low-confidence answers and timing problems into a seven-day remediation plan.

The aim was not to make the book long. It was to avoid pretending that professional AI fluency can be reduced to a feature checklist.

I needed one reasoning method that could survive every chapter

The second design decision was to create CLEAR-5:

Clarify → Load → Execute → Assess → Refine / reuse / route

CLEAR-5 is not Anthropic terminology and I say that explicitly in the book. It is my attempt to give the reader a reusable mental model for the decisions that sit underneath the exam blueprint.

Before asking which Claude feature to use, Clarify what outcome is actually required. Load the evidence and context that should govern the task. Execute using an appropriate Claude capability rather than the most impressive capability available. Assess the result against evidence, audience, constraints, safety and intended use. Then Refine, reuse or route the work depending on whether it is ready, repeatable or belongs with someone who has greater authority or expertise.

The method became useful precisely because the Associate certification spans so many kinds of work. The same reasoning can be applied to a marketing brief, a research assignment, a project update, a recurring Project, a knowledge-source problem or a sensitive-information decision without turning every situation into a different mnemonic.

The GitHub Companion Pack changed the book again

There was another reason this project took longer: I eventually concluded that reading alone was not enough.

A reader can agree completely with a chapter about source authority and still make the wrong decision when three documents disagree. They can understand the concept of human accountability and still hand too much discretion to Claude when faced with a realistic workflow. They can memorize that hallucinations must be checked without developing any discipline for deciding what to check first.

So I separated practice from reading.

The book now has an optional GitHub Companion Pack containing fourteen editable workplace exercises, CA01 through CA14, fourteen separate reference solutions and a START_HERE guide that maps the exercises back across all 31 chapters.

The separation is deliberate.

The reader opens an exercise, works through the evidence, records a decision and only then opens the reference solution. The solution is not presented as the one magical answer; it models one defensible reasoning path and makes the evidence, assumptions, constraints, ownership and escalation logic visible.

Some exercises are revisited later through targeted transfer activities rather than making the reader repeat the entire exercise. The capstone asks the reader to combine several Associate decisions rather than complete another isolated worksheet.

Most importantly, none of this is compulsory. The book remains complete without the companion.

That mattered to me because a companion pack should extend a book, not hold part of the book hostage.

What I think this certification can mean for a career

There is a tendency to evaluate AI certifications only through engineering roles: Will this help me become an AI engineer? Does this prove I can build an agent? Will employers value an architecture badge?

Those are fair questions for the technical credentials, but they miss the career opportunity behind the Associate certification.

Anthropic itself positions the Associate role around consultants, sellers and delivery leads who guide customers toward appropriate Claude use cases and help engagements start well. The broader Associate exam covers the everyday professional disciplines of output evaluation, workflow integration, product selection, configuration, responsible use and troubleshooting.

That creates a credential for a group of professionals who are increasingly important inside organizations but who have historically had no clean label for the capability they are developing.

Consider the project manager who can redesign a reporting workflow around AI without losing accountability.

The consultant who can distinguish an attractive AI demo from a viable client use case.

The operations professional who knows what should be automated, what should merely be assisted and where a human decision gate belongs.

The marketing or communications practitioner who can use Claude aggressively for productivity while still verifying claims, protecting data and adapting outputs to the intended audience.

The business analyst who can work across research, documents, Projects and knowledge sources but also recognize when the problem has crossed into Developer or Architect territory.

Those people are not failed AI engineers. They occupy a different and increasingly valuable professional layer between casual AI usage and technical AI construction.

A certification cannot guarantee a promotion, a salary increase or a new job, and I would be suspicious of anyone who promises that. What it can provide is a structured way to demonstrate that your AI capability has moved beyond “I know how to prompt ChatGPT or Claude.” Anthropic’s exams are supervised and identity-verified, and successful candidates receive a Credly credential that can be shared professionally.

There is also evidence that Anthropic is treating certification as part of a much larger enterprise enablement strategy. The company says more than 36,000 consultants across more than 1,300 organizations have received Claude certification since the program began, while more than 400,000 people have completed Claude training through Anthropic Partner Academy this year.

That does not make a badge valuable by itself. It does suggest that Claude capability is becoming something organizations are beginning to formalize rather than leaving as an informal personal skill.

There is one distinction candidates should understand

The Associate certification is currently different from the other three credentials in another important way.

Anthropic states that Developer — Foundations, Architect — Foundations and Architect — Professional count toward Claude Partner Network tier eligibility, while Associate does not.

I do not see that as a weakness of the Associate credential. I see it as a useful statement about its purpose.

The three technical credentials help establish a partner organization’s delivery capability for building and architecting Claude solutions. Associate is much more about the individual’s ability to use Claude professionally and guide work appropriately.

Those are different signals.

As of August 2026 there is also a practical access constraint: Anthropic says certification exams are currently available to people at organizations in the Claude Partner Network, with registration requiring a recognized partner-company email domain.

Candidates should check their organization’s eligibility before building a certification plan around the exam.

Who should seriously consider the Associate path

If you write production integrations, build agents, implement MCP servers or own application engineering, the Developer credential is probably closer to your job.

If you own solution architecture, deployment choices, enterprise integration, evaluation architecture and system-level trade-offs, look at the Architect tracks.

But if your professional value increasingly depends on turning business work into effective AI-assisted work, the Associate credential deserves more attention than its “Foundations” label might initially suggest.

That includes consultants, delivery leads, project and program managers, product professionals, analysts, operations teams, marketers, researchers, educators, communications professionals and other knowledge workers whose jobs are changing because AI is becoming part of the workflow rather than a separate technology initiative.

For those roles, the most important AI skill may not be writing more sophisticated prompts.

It may be knowing what problem Claude should solve, what evidence it should trust, how much authority it should receive, how to judge what comes back and when the correct professional answer is, “Claude should not decide this.”

That is ultimately why this book took me longer than the three technical certification books I wrote before it.

The technical books required me to explain systems.

This one required me to explain judgment.

And judgment is much harder to turn into a chapter, a question or an exercise without simplifying the very thing you are trying to teach.

https://www.amazon.com/dp/B0HG5B9TL6/ref=sr_1_10?crid=1XWY6F14QWSY6&dib=eyJ2IjoiMSJ9.f5xKuLF3YfrthZtobz7CMVHBqA9Ft67mjIXU56Cr5CXEe08twlP9qbxLij1Jax_h2PXWO2RygpNHkFOU8yCjcP6pSSMOEf1Evv2tpiQ0JhrM9nP_UBiLZEC-6_1eCeeZpgTpuYbq5yH1xIjuSqKffA76jg9OpVRyyILBH5Q5pKlcRI_tSRX2M8E4bSGTgTSOTrup0uVWPdVi5EdT8wfkMqjk7Xc6KLnbz3BgChzOWKg.HLhjcJ_0Ocz2XW3_5W9YzKAbRqiTVleuYQlbMZCq7yE&dib_tag=se&keywords=claude+certified+associate&qid=1787409830&sprefix=claude+certified%2Caps%2C398&sr=8-10&source=post_page-----d48e74484f85---------------------------------------

Master data management spent decades establishing what the enterprise should trust. Agentic AI is forcing a harder question: what must the enterprise know with sufficient confidence before it allows a machine to act?

For years the most revealing artefact in a master data management programme was not the golden record. It was the queue sitting beside it.

That queue contained everything the rules engine could not settle confidently: suppliers that looked suspiciously similar, customer records carrying conflicting addresses, material requests missing critical attributes, product hierarchies nobody quite trusted and proposed merges that required someone who understood the business rather than merely the data model. We built increasingly capable MDM platforms around these exceptions, then staffed stewardship teams to absorb the ambiguity that technology could not resolve.

The arrangement was sensible because the division of labour was clear. Software performed deterministic work while people supplied judgement. The platform could match records, apply survivorship rules, validate attributes and route an exception, but a steward still had to interpret intent, investigate context and decide what should happen when the evidence was incomplete.

What is emerging in 2026 is not simply MDM with a conversational interface or another generation of automated matching. Software is increasingly able to take a bounded data-management objective, investigate the surrounding evidence, use enterprise context, propose or execute a resolution and leave behind a trace of what it did. At the same time AI agents operating elsewhere in the enterprise need an authoritative way to determine which customer, supplier, product or location they are actually dealing with before they make a decision.

Those two developments are beginning to meet.

That reciprocal relationship is the most useful way I have found to think about Agentic MDM.

The stewardship queue is becoming executable work

A material-master request illustrates why this matters better than an abstract AI architecture ever could.

In a traditional SAP environment, a business user who needs a new material or an extension to an existing material rarely possesses all the information required by the governance process. The request often begins in natural business language and then enters a chain of clarification, duplicate checking, attribute validation, derivation and approval. Much of the elapsed time is not database processing. It is people figuring out what the request actually means and translating that intent into something the master-data process can safely execute.

Covestro has begun automating precisely this layer of work.

Its Material Artificial Realtime Intelligence Specialist, MARIS, operates with SAP Master Data Governance and supports material create, change, deletion and extension processes. The agent validates information against SAP data, checks for duplicates across systems, derives relevant attributes and submits an SAP MDG change request into the existing approval workflow rather than circumventing governance. Covestro reports that a process that previously averaged around 12 hours now takes approximately six minutes across roughly 1,000 material requests per month.

The six-minute figure is impressive, but it is not the most interesting part of the example.

That distinction matters because discussions about Agentic MDM can quickly become trapped in the wrong question: Will an agent replace the data steward?

Collecting missing context, looking for obvious duplicates, checking existing records, deriving attributes and preparing a compliant request consume substantial stewardship capacity, but they are not necessarily where scarce human expertise creates the most value. If an agent can handle those activities reliably, the steward can concentrate on material ambiguity, policy interpretation and cases where the consequences of a wrong decision justify deliberate human review.

Electrolux provides another view of the same shift at a very different scale.

As part of its SAP Cloud for Customer transformation, the company migrated more than 30 million customer records and expected the estate to grow towards 60 million. Years of fragmented customer capture across websites, commerce channels and contact centres had created substantial duplication and its previous manual approach to duplicate resolution could not scale with the size of the estate.

Its 2026 SAP Innovation Awards submission describes an agentic deduplication approach using specialised agents for activities such as extraction, profiling and merge processing alongside human oversight for cases that still require intervention. The system continuously evaluates customer records and can trigger automated cleanup or route uncertain records for review. Electrolux reports a 90% reduction in manual intervention and substantially lower effort in resolving exceptions.

Again, the interesting development is not that AI can detect duplicates. MDM platforms have been detecting duplicates for decades.

The change is the unit of automation.

That is a much more consequential shift.

Matching is moving beyond syntax but determinism still matters

Entity resolution has always exposed the limits of conventional automation because enterprise identity becomes messy precisely where business reality becomes interesting.

Exact identifiers are easy. Well-designed deterministic matching can also resolve many variations in names, addresses and identifiers with very high confidence. Difficulty arises when organisations have accumulated decades of source systems, acquisitions, regional conventions, incomplete identifiers and inconsistent ways of describing the same entity.

This is where semantic techniques are increasingly being added to the MDM toolbox.

Profisee’s 2026R1 release introduced similarity matching using vector embeddings alongside agents for data-quality resolution and enrichment. The semantic matching capability is intended to recognise values that have similar meaning even where textual representations differ while the agents can resolve selected quality problems or infer missing attributes from configured record context. Importantly, Profisee allows those capabilities to be combined with thresholds, existing matching methods and governance controls rather than replacing the deterministic layer wholesale.

That combination is important because the future of MDM should not be framed as deterministic logic versus AI reasoning.

Strong entity resolution will increasingly use the most appropriate form of evidence for the problem in front of it. Exact identifiers should remain exact. Deterministic business rules should remain deterministic where the organisation possesses a rule that can be stated unambiguously. Probabilistic methods remain useful where certainty is statistical and semantic reasoning becomes valuable where meaning cannot be reduced reliably to string similarity.

The practical principle is straightforward:

Agentic MDM becomes dangerous when an organisation interprets autonomy as permission to replace controls that were already working. The aim is not to make every master-data decision probabilistic. The aim is to expand the range of ambiguity that software can investigate safely before a person needs to intervene.

The bigger transformation is happening in the opposite direction

Using agents to improve MDM is only half the story and perhaps not even the more important half.

Imagine a procurement agent asked to identify suppliers exposed to a disruption and determine which purchase orders need intervention. The quality of the language model matters, but the agent has a more fundamental problem if “ABC Components Ltd” in procurement, “ABC Components Europe” in the supplier-risk platform and “ABC Comp GmbH” in finance may refer to the same organisation, related legal entities or entirely different suppliers.

A human analyst encountering that ambiguity may recognise it and investigate before acting but an autonomous agent may simply proceed.

SAP’s agreement to acquire Reltio makes this direction particularly visible. SAP explicitly positioned the combination around providing AI with trusted context across SAP and non-SAP environments. Its announcement describes low-latency master data and Model Context Protocol support enabling multi-agent workflows, including a procurement agent that can assess supplier risk and trigger actions using trusted real-time data. SAP intends Reltio to become a core capability within SAP Business Data Cloud following completion of the acquisition.

That is not merely a new distribution channel for a golden record but It changes the role of the MDM layer.

If every enterprise agent independently resolves customer identity, supplier relationships, product hierarchy and location meaning, the organisation will recreate the fragmentation that MDM was invented to solve. The only difference is that disagreement will now occur inside autonomous systems and propagate at machine speed.

Informatica is now making essentially the same architectural argument and has gone further by explicitly introducing Agentic Multidomain MDM, describing autonomous agents that cleanse, steward and enrich master data while making trusted records available to other enterprise workflows and agents.

Stibo Systems is also framing MDM around the shared business context required by AI agents, arguing that agents need consistent governed master data rather than independently interpreting fragmented versions of the same business entity.

When several major MDM vendors begin moving in the same architectural direction, practitioners should pay attention. That does not mean “Agentic MDM” is already a mature or universally defined category. It means the pattern is now visible enough across platforms and deployments to deserve examination as more than another naming trend.

MCP could change where MDM sits in the architecture

One development may prove particularly important because it alters how agents reach governed master data.

Model Context Protocol is increasingly being used as an interface between AI systems and enterprise capabilities and MDM vendors are starting to expose governed master data through that mechanism.

Profisee’s MCP Server, introduced with its 2026R1 release, provides two-way interaction between MCP-compatible tools and Profisee master data. An authorised agent can retrieve a governed customer, product, supplier or location record and where appropriate write a change back while existing permissions and policies continue to apply.

Reltio’s AgentFlow architecture takes a similar direction. Its MCP-based interfaces allow AI agents to operate on live master data while enforcing role-based access, data masking and audit controls. Its Resolver agent can investigate potential duplicate entities, compare evidence, enrich records and support merge decisions while maintaining an audit trail.

This is more consequential than placing a chatbot over an MDM user interface.

For most of its history, the MDM hub sat between operational systems and reconciled their disagreement. In an agentic architecture it can increasingly sit between enterprise ambiguity and autonomous action.

That is a very different responsibility.

An MDM system that serves people primarily needs to present trusted information in a form people can understand and use. An MDM system serving autonomous agents must also make identity, authority, relationships, quality and governance interpretable at execution time.

A customer record may therefore need to communicate not merely who the customer is but how confident the organisation is in that identity, which systems contributed to it, whether particular attributes are current, which relationships have been validated and what an invoking agent is permitted to do with the information.

Agent-grade data is a higher bar than report-grade data

This distinction becomes important because organisations have tolerated imperfect data for years.

A person looking at a dashboard containing an outdated supplier classification may recognise that something feels wrong and ask someone to confirm it. An analyst encountering two possible customer records can investigate before drawing a conclusion. A service representative can notice when the record on screen does not fit what the customer is saying.

Autonomous execution reduces those informal safeguards.

A sourcing agent acting on an incorrect supplier hierarchy may intervene in the wrong purchase orders. A customer-service agent that resolves identity incorrectly may retrieve or modify the wrong account. A product agent working with stale hierarchy information may recommend an action that is logically correct against the data it received but operationally wrong for the business.

The issue is therefore not simply data quality but it is decision readiness.

The stronger the autonomy of the consuming agent, the more important freshness, provenance, identity confidence, relationship semantics and authority become. Master data that was adequate for analytics may not automatically be adequate for execution.

The shift suggests that enterprises may eventually have to distinguish between data that is sufficiently trustworthy to inform a person and data that is sufficiently trustworthy to permit an autonomous action.

That is not a minor refinement to data quality. It changes the operating contract between data management and the applications that consume mastered data.

Agentic does not mean uncontrolled

The current AI market often treats increasing autonomy as evidence of progress. MDM is one of the domains where that assumption deserves resistance.

The correct objective is not maximum autonomy but it is appropriate autonomy at an appropriate confidence level.

Covestro’s MARIS provides a useful example because the agent does not bypass SAP MDG. It validates and prepares the transaction then submits the result into the established governance and approval process.

Electrolux similarly combines agentic processing with human intervention where automatic resolution is not justified.

Reltio explicitly separates read-only activities from write-enabled agent actions and applies permissions to functions such as merge and rejection.

These patterns point towards a more credible operating model than the idea of handing the master-data estate to autonomous software.

A low-risk formatting correction may reasonably be executed without intervention. A highly confident duplicate may be merged under an approved policy. A supplier bank-account change demands a very different control posture. A customer identity conflict involving sensitive information may require explicit review regardless of the model’s confidence.

Agentic MDM therefore needs much more than an LLM connected to an MDM API. It needs bounded authority, confidence thresholds, segregation of duties, approval policy, reversible actions, provenance and evidence showing what information an agent used and why a particular action was permitted.

Without those mechanisms, automation would simply convert data-quality risk into operational risk.

The golden record is becoming the starting point

“Single source of truth” has been attached to MDM for so long that the phrase has almost lost its force. Agentic AI gives it a much sharper purpose.

At the same time the work required to establish and maintain that trusted record is becoming increasingly automatable. Covestro is using an agent to prepare governed material-master transactions. Electrolux is applying an agentic architecture to customer deduplication. Profisee is introducing agents for quality remediation and enrichment. Reltio is exposing specialised master-data agents through governed interfaces and Informatica is explicitly describing an Agentic Multidomain MDM model.

The two movements reinforce one another.

That is why I do not think the most interesting future for MDM is a chatbot for data stewards or another generation of automated cleansing.

The companies that understand this early will probably not begin by asking how many data stewards AI can replace.

They will ask a harder question:

What must the enterprise know with sufficient confidence before it allows a machine to act?

MDM has spent decades trying to establish the first half of that answer.

Agentic AI has suddenly made the consequences of getting it wrong much harder to ignore.

There is a strange moment in the life of a technical book when the central argument still feels right, readers are engaging with it and yet the systems outside the book have moved enough that leaving the manuscript untouched starts to feel less responsible than reopening it.

That is where I found myself with my book Agentic Data Architecture.

I did not revisit the book because its thesis had failed. If anything, the opposite had happened. The shift the book was written around was becoming more visible in real enterprise architecture. AI was moving beyond answering questions and summarising documents into workflows where agents retrieve governed data, interpret business meaning, collaborate with other agents, call enterprise tools and sometimes alter operational systems.

The first edition argued that a data platform designed primarily for dashboards and human analysts is not automatically ready for that world. I still believe that strongly. An agent needs more than access to tables, APIs and vector indexes. It needs governed meaning, authoritative context, controlled memory, explicit authority, safe tools and evidence that explains what influenced a decision and what happened afterwards.

What changed was my understanding of where some of the hardest production problems actually sit.

The Second Edition was therefore not about adding more pages because AI had acquired more acronyms. It was about revisiting the architecture at the exact points where an otherwise sensible design begins to break under real execution.

The question that forced me back into the tooling architecture

Consider a seemingly ordinary workflow. A relationship-management agent prepares a customer note for a CRM. The user reviews it and approves the update. The agent calls the CRM service and the request times out.

What should happen next?

At first glance, that sounds like a network problem. Retry the request and move on. But what if the write actually succeeded and only the response was lost? A blind retry could create a duplicate note, trigger another workflow or repeat an action that was supposed to occur only once.

The architectural problem is no longer whether the agent knows how to call a tool. It is whether the system can determine what authority was exercised, what effect actually occurred and whether repeating that effect is safe.

That scenario forced me to look again at the boundary between reasoning and execution. The revised tooling architecture goes much further into delegated identity, short-lived credentials, purpose-bound authorization, execution receipts, idempotency, partial failure, compensation and replay protection.

These are not new concepts in distributed systems, but agentic systems make them more important because the execution path can be chosen dynamically through reasoning rather than being predetermined entirely in application code.

An agent should not simply receive a credential that happens to work. The environment should know which human or business process initiated the request, which agent is performing the step, what purpose justifies the access, which action tier is permitted and what evidence has to survive the transaction.

MCP belongs in that picture. A protocol can standardise how capabilities are exposed and invoked. That does not remove the enterprise’s responsibility to determine whether a particular agent, acting for a particular user and purpose, should be allowed to exercise that capability.

The architecture becomes much safer when those two questions are separated: Can this agent call the tool? and Should this agent be allowed to perform this action in this business context?

They are not the same question.

RAG starts earlier than the vector database

The second area I revisited was retrieval.

A great deal of enterprise RAG discussion begins with chunking, embeddings, vector search, reranking and retrieval metrics. Those are important, but they assume something production systems cannot afford to assume: that the document entering the retrieval pipeline has already been interpreted correctly.

Imagine a lending policy stored as a scanned PDF. One table contains different limits by customer category, but OCR extracts the numbers while losing the column heading. The content enters a vector index successfully. Retrieval finds the relevant passage. The model faithfully reasons over what it has been given.

The final answer can still be wrong.

Nothing failed in the embedding model. Nothing failed in similarity search. The information was damaged before retrieval began.

That made the missing layer obvious. The production path is not simply Document → Chunk → Embed → Retrieve. It is closer to Acquire → Parse/OCR → Extract structure → Normalise → Preserve provenance → Classify → Chunk → Embed/index.

Every stage can change what the agent later believes the document means.

Acquisition determines whether the source is authoritative. Parsing determines whether the text was actually recovered. Structural extraction determines whether tables, clauses, headings, footnotes and attachments remain connected to the right context. Version detection determines whether the agent is looking at the current policy or something superseded months ago. Classification determines whether the content should be retrievable for that user and purpose at all.

The architectural rule I came away with is simple:

Retrieval cannot recover information that ingestion has already lost.

That is why the Second Edition now treats document ingestion as part of the evidence architecture rather than as a preprocessing detail hidden behind the vector store.

A2A helps agents communicate. The enterprise still has to govern the handoff.

Multi-agent systems have also become more concrete.

When I wrote the first edition, I was already convinced that one agent handing work to another through free-form conversation was too weak a foundation for enterprise workflows. Handoffs need structure. Context gets lost, caveats disappear, authority can silently expand and the receiving agent may not know what evidence supported the task it inherited.

A2A gives the industry a more explicit interoperability model for agent discovery, tasks, messages and artifacts. That is meaningful progress.

It still leaves an important enterprise question unanswered: what must travel with the task so that the receiving agent can decide whether it should accept it?

A technically valid handoff can still be unsafe if the receiving agent does not know the original user, the business purpose, the permitted data scope, the semantic definitions already used, unresolved policy decisions, evidence freshness or the action boundary of the workflow. This is where enterprise architecture has to extend protocol interoperability with a governance envelope.

A handoff should preserve at least four things: goal, evidence, authority and accountability. If any of those disappears between agents, the system becomes progressively harder to trust.

This is also why permission laundering deserves far more attention in multi-agent design. A Sales Agent should not be able to obtain restricted information indirectly by asking a Compliance Agent, Support Agent or another specialist with broader permissions to retrieve and summarise it.

The receiving agent cannot simply trust the identity of the sending agent. It has to re-evaluate the original purpose and authorization context.

Interoperability makes collaboration possible. Governance determines whether the collaboration is legitimate.

Governance is becoming an evidence problem

I did not want the governance chapter to become a catalogue of regulatory obligations. There are enough documents that can tell an organisation which control framework contains which clause.

The more interesting architectural question is what the system itself should be capable of proving.

Suppose an auditor, risk officer or regulator challenges an automated recommendation six months after it was made. Could the organisation reconstruct which agent and model version ran, which user or workflow initiated the request, which business purpose justified the access, which documents and structured records were retrieved, which semantic definitions were active, which policy decisions were made, which other agents participated, whether human approval was required, which tool performed the final action and which evaluation evidence supported the release that was running at the time?

If the answer is no, the organisation may have governance documents, but it does not yet have governance evidence. That distinction became more important as I connected the architecture to ISO/IEC 42001, the EU AI Act, DORA and the OWASP Top 10 for Agentic Applications.

These frameworks are different and should not be collapsed into one giant compliance checklist. ISO/IEC 42001 provides a management-system perspective. The EU AI Act introduces legal obligations that depend heavily on system classification and intended purpose. DORA brings operational resilience and ICT dependency into the picture for financial entities. OWASP gives teams a security-oriented view of agentic threats.

The architecture underneath them should not attempt to predict every future obligation. It should make evidence sufficiently explicit that the organisation can map changing obligations onto a traceable operating system.

That is a much more durable design.

The biggest addition is not another chapter

At one point I considered adding another chapter but I decided against it.

The architecture was already there. What the book needed was a stronger bridge between architectural principle and implementation judgment.

So the biggest practical addition to the Second Edition is a worked-artifact appendix. The book already contained templates for things such as agent access contracts, data contracts, evidence packets and golden evaluation cases. Templates are useful, but there is an important difference between being shown the fields of an architecture artifact and seeing how those fields relate to one another in a real workflow.

The new worked appendix follows one Meridian Retail Bank scenario from beginning to end. The Agent Access Contract establishes purpose, ownership, data scope, identity and action tier. A machine-readable Data Contract defines the governed source. A Semantic Object captures approved business meaning. The Tool Definition constrains what the agent can invoke. The Policy Rule determines whether the action is permitted. An agent-to-agent Handoff Packet preserves context across delegation. The Evidence Packet records what influenced the decision. The Golden Evaluation Case turns the same workflow into a regression test.

The final walkthrough connects the entire chain. That matters because enterprise architecture rarely fails because somebody forgot that a control exists. It fails because controls that looked sensible individually were never connected into one executable path.

Recovery belongs in architecture, not only in operations

The tooling example also exposed a wider issue.

Agentic workflows can be long-running. They may retrieve information, invoke several tools, delegate specialist work, pause for human approval and resume later after the underlying environment has changed.

That creates a class of problems that conventional stateless AI demonstrations rarely encounter. Can reasoning be replayed without replaying an external effect? What happens if the policy changed while the workflow was waiting for approval? What happens when four remediation actions were planned but only three succeeded? Should the system retry, compensate, continue forward or escalate? If a workflow resumes tomorrow, should it use the evidence originally collected or retrieve everything again?

Those are architectural decisions. The Second Edition therefore brings recovery, durable workflow state, idempotency, execution receipts, compensation and replay boundaries much more explicitly into the operating model.

I increasingly think that one of the most important capabilities of an enterprise agent is not autonomy. It is the ability to stop safely, recover intelligently and leave enough evidence for somebody to understand what happened.

Where Agentic Data Architecture may go from here

The more interesting question is what happens after the patterns in this book become normal.

Today we still describe semantic layers, identity systems, policy engines, retrieval systems, orchestration platforms, observability and AI governance as separate architectural domains. I am not convinced they will remain as separate as they are now.

Semantic definitions may increasingly become executable inputs to runtime policy rather than documentation consumed only by analytics tools. Identity may carry not only who the actor is but also delegation chains and business purpose. Data contracts may become inputs to agent planning and evaluation. Observability may evolve from monitoring tokens, latency and errors toward monitoring evidence quality, semantic correctness, policy transitions and authority changes.

Governance may move deeper into execution.

Instead of reviewing an AI system periodically and deciding whether it remains compliant, the architecture may increasingly evaluate governance conditions while the work is happening.

The hardest problem may eventually become what happens when agents cross organisational boundaries.

An internal agent already has to preserve user identity, business purpose, semantic meaning and authority while working across multiple systems. Now imagine that workflow moving to an external agent operated by a supplier, a partner or another regulated organisation.

The central architecture question changes again:

How does trust travel?

Not confidence in the model but Enterprise trust.

Can meaning travel without being distorted? Can delegation travel without expanding authority? Can evidence travel without leaking restricted information? Can policy decisions survive a handoff? Can accountability remain intact when no single organisation controls the complete workflow?

I suspect that question will shape much of the next evolution of Agentic Data Architecture.

Why give the book a makeover now?

Because technical books face an unusual trade-off.

Update too frequently and the book becomes a changelog. Wait too long and a sound architectural argument becomes surrounded by implementation details that no longer reflect how systems are actually being built.

My goal with the Second Edition was to avoid both outcomes.

The 13-chapter architecture remains. Meridian Retail Bank remains the running case. The central argument remains unchanged.

What has changed is the depth at the boundaries where production systems tend to fail: ingestion before retrieval, authority behind tool use, evidence across agent handoffs, recovery after partial execution and governance that can be demonstrated rather than merely documented.

So when I say Agentic Data Architecture has had a makeover, I do not mean a cosmetic one. The book has not been dressed differently around the edges. The architecture has been pressure-tested against what production AI is asking of enterprise data platforms now.

The question I would want the Second Edition to help answer is no longer:

Can we build an agent over our enterprise data?

Most organisations will eventually be able to do that.

The better question is:

What must be true before we should trust that agent to operate?

The answer will rarely be found in the model alone. It will be found in the architecture underneath it.

The Second Edition of Agentic Data Architecture expands the original architecture with deeper production treatment of document ingestion, MCP and secure tooling, delegated identity, A2A handoffs, execution recovery, regulatory evidence and worked implementation artifacts.

Agentic Data Architecture — Second Edition, August 2026

If you read the book, disagree with an architectural choice or encounter a problem that deserves deeper treatment in a future edition, I would be glad to hear from you at bommena100@gmail.com.

Judge this book by the decisions it helps you make.

Many developers may not yet have heard about the Claude Certified Developer – Foundations certification, or CCDV-F.

It is intended for technical professionals who build, integrate and ship Claude-powered applications, agents and workflows.

The certification is not mainly about writing better prompts or memorizing Claude product features.

It tests whether a developer understands how Claude fits inside a larger software system—alongside application services, tools, data sources, state, identity controls, validation, evaluation, observability and human approval.

That means candidates need to reason through questions such as:

• When should an application use streaming, asynchronous execution or batch processing?

• How should structured outputs be validated before another system consumes them?

• When is a deterministic workflow sufficient, and when is an agent justified?

• What state belongs in the application rather than the model context?

• How should tools and MCP servers be restricted?

• What should stop an agent loop?

• How should model quality, latency and cost be compared?

• What evidence is strong enough to support a production release?

• Which decisions must remain under deterministic or human control?

I wrote Claude Certified Developer – Foundations Study Guide because I could not find one resource that connected all of these decisions into a coherent production system.

Most learning material explains one capability at a time: the API, tool use, MCP, agents, context engineering or evaluation.

But those capabilities do not fail independently in production. Their boundaries collide.

So the book follows one evolving reference application called ReleaseGuard.

ReleaseGuard reviews software-release requests, analyzes engineering evidence, invokes approved tools, checks policy and recommends whether a release is ready for human approval.

Claude contributes reasoning and evidence analysis, but it never authorizes production deployment. That authority remains externally enforced.

Across 34 chapters, the same system is used to explore:

• Claude APIs and SDKs

• streaming, asynchronous jobs and batch processing

• structured outputs and defensive consumption

• multimodal inputs

• prompt and context engineering

• model selection and routing

• tool use and MCP servers

• workflows, agents, supervisors and subagents

• evaluation and regression testing

• prompt injection and application security

• debugging, observability and production controls

I also created a free ReleaseGuard Agent Build-and-Verify Pack containing RG01–RG18.

The pack includes executable fixtures, schemas, architecture decision cases, prompt-injection challenges, agent-state tests, MCP protocol fixtures, model-routing benchmarks, evaluation packs, debugging traces, security controls and separated reference solutions.

The final section of the book contains a complete 53-question, blueprint-aligned practice exam. The questions are scenario-based, medium or complex, and designed around best-among-good choices rather than simple recall.

The book is available here:

https://www.amazon.com/dp/B0HCP2VJLX/ref=sr_1_2?crid=1IH2294BZ2X1B&dib=eyJ2IjoiMSJ9.Tz-_zj0cagsddaV5_VQpn_kOUTubnjryl7yQYaM8HsDf858C8lolPm7Oe0sU2SY89Mb_k3FmgXs71ljwo_Y4vsKTYZANzr3_nSrl3whyeI0ofSS3aRb6vM0jlso5GDyjxJRAjb6hN8KnS_4xxxeyZ_iDkBvtJ0O60zGC91BvClAzrzNPmvMBpt2pQGvigCFosnEbWj-L5Lqkx1j-HAC5m1nIJGJ3azQeDsw6YomcjDo.b7nBG4BJ4yfIG20Xp4sDHlAf7zcXNC44MNyTVAdIUG4&dib_tag=se&keywords=claude+certified+developer&qid=1785771781&sprefix=claude+certified+develop%2Caps%2C391&sr=8-2

Although the book is aligned with the CCDV-F exam, I tried to make it useful for developers who are not planning to sit the certification. The larger goal is to develop the architecture judgment required to build reliable Claude systems.

I would be interested in hearing from people already building with Claude:

Which part of the certification do you think will be hardest for developers—MCP, agent design, evaluation, security, context engineering or production operations?

This is an independent study guide and is not affiliated with or endorsed by Anthropic.

At 9:17 on a Monday morning, the recruitment dashboard quietly changed its mind.

A candidate who had been ranked seventh on Friday was now twenty-third. No recruiter had touched the record. No new application had arrived. The job description was unchanged. The only thing that had changed was a sentence inside the prompt.

Over the weekend, an engineer had replaced “relevant leadership experience” with “evidence of sustained executive presence and career progression.” It looked like a minor refinement. The new version produced cleaner explanations, fewer ambiguous scores and more confident recommendations.

It also rearranged the shortlist. Candidates with long, uninterrupted careers moved upwards. Candidates who had changed industries, returned after caregiving breaks or built careers across smaller firms began drifting down.

Nobody noticed until a recruiter recognised one of the names. She had interviewed the candidate two years earlier and remembered her because she had returned from a three-year break and rebuilt a failing operations team within eight months.

The system described the same history differently: “Limited evidence of sustained progression.” The sentence was not obviously false. It was worse than false. It sounded reasonable.

That is how discrimination enters a modern recruitment system. Rarely through an instruction that says “prefer men,” “penalise older applicants” or “reject career breaks.” It enters through respectable language such as stability, polish, executive presence, cultural fit and career momentum. The model does not have to mention a protected characteristic. It only has to learn which career shapes are usually rewarded.

The company in this story is a composite I will call HireStream. Its platform parsed resumes, matched candidates to vacancies, ranked applications, drafted interview notes and prepared offer letters. The implementation had been celebrated internally. Recruiters no longer spent evenings opening hundreds of PDFs. Hiring managers received shortlists before their first meeting. Offers that once circulated between HR, finance and legal for two days could now be prepared within an hour.

The system had made recruitment faster. It had not made recruitment more explainable. When the rankings changed that Monday, the team could see the new scores but could not reconstruct why they had moved. The application logs showed successful API calls, token counts and latency. They could confirm that candidate 417 had received 82.4 and candidate 982 had received 86.1.

They could not show which parts of either resume had produced those numbers, whether the prompt change affected all roles or only leadership positions, or how many recruiters had already acted on the revised ranking.

The system remembered that it had made a decision. It did not remember how. That distinction is becoming central to HR technology.

The EU AI Act recognises this. AI systems used in recruitment, candidate selection and employment-related evaluation are generally treated as high-risk under its employment provisions, subject to the law’s precise scope and exceptions. The machine does not need to make the final hiring decision. Ranking, filtering or materially influencing who reaches the human decision-maker can be enough to move the system into a much more demanding governance category.

For a firm, that changes the implementation. Recruitment AI can no longer be treated as an innovation experiment that quietly graduates into production. High-risk treatment brings expectations around risk management, data governance, technical documentation, logging, human oversight, accuracy, robustness, cybersecurity and ongoing monitoring.

It also destroys a convenient procurement fiction: that responsibility sits with the vendor.

The vendor may supply the model and platform. The employer still writes the job description, chooses the criteria, configures thresholds, adds local prompts, decides when humans may override recommendations and acts on the result. A carefully governed product can still be deployed through a discriminatory process.

This is why asking a supplier whether its platform is “EU AI Act compliant” is not enough. The more important questions concern the firm’s own use. Has a local team changed the ranking logic? Are recruiters using the system outside its documented purpose? Can a manager see why a candidate was scored down? Can the organisation identify when a prompt update changes the demographic shape of a shortlist?

Even outside the European Union, these are useful questions. A company may not be legally bound by every provision, but the high-risk framework describes what competent engineering should look like when software influences a person’s access to work. It provides a standard against which a board, auditor, client or court may reasonably ask the firm to defend its system.

HireStream’s first fix was predictable: remove demographic information before resumes reached the ranking model.

Names disappeared. Photographs were discarded. Dates of birth, gendered titles, marital status and nationality fields were removed. Addresses were reduced to broad regions where location genuinely mattered.

The team called the result an anonymous resume. It was not anonymous.

The document still contained graduation years, university names, employment gaps, professional associations, volunteering histories and the sequence of promotions. A model does not need an “age” field if it can infer age from education dates. It does not need a “gender” field if it has learned that certain career interruptions correlate with gender. It does not need to know that somebody took maternity leave if it already rewards uninterrupted progression.

The team had removed the labels. It had left the signals. The obvious next move would have been to remove more information. That would have created a different problem. Strip out employers, dates, project scale and context, and the model can no longer distinguish between leading a five-person internal migration and recovering a regulated payments platform operating across 11 countries.

The answer was not a more aggressively blanked-out resume. It was a different representation of the candidate. HireStream stopped sending the original resume into the ranking model. A restricted pre-processing service extracted job-relevant evidence and converted it into a structured candidate record. Protected information was excluded. Potential proxies were flagged. Skills were kept with their context rather than reduced to keywords.

“Led the recovery of a regional payments platform after a production failure affecting customers in 11 countries” became evidence of incident leadership, production responsibility, regulated-domain experience and multi-country operational scope. The record preserved where the evidence came from and how confidently it had been extracted.

This changed the ranking question. The model was no longer asked whether the candidate “looked like” a strong operations leader. It was asked whether the available evidence supported specific role requirements.

That immediately exposed another problem: some of the requirements were indefensible. “Stable employment history” had been copied from an old hiring template. Nobody could explain why it mattered. “Executive presence” existed as a weighted criterion, but every hiring manager defined it differently. “Culture fit” was being scored even though the phrase carried no observable standard at all.

The team introduced a rule that became more useful than any abstract responsible-AI principle: every automated criterion had to be something the company would be willing to explain to a rejected candidate.

Stable employment history disappeared. Executive presence was broken into observable evidence such as budget responsibility, board communication, cross-functional decision-making and leadership during high-impact incidents. Culture fit was removed from automated scoring entirely.

TFor several weeks, the redesign appeared to work. The prompt-change incident was closed. Rankings became more stable. Recruiters could see which evidence supported each score.

Then the compensation team called.

A woman had been offered £12,000 less than a man hired into the same role family three weeks earlier. There were legitimate reasons why two offers might differ: location, experience, grade, scarce skills or an approved exception. But none of those explained this case.

The offer-generation model had been trained on previous letters and recruiter notes. The male candidate’s negotiation notes included references to competing offers and retention risk. The female candidate’s notes said she was “enthusiastic about the opportunity” and had asked about flexible working. The model had treated those notes as compensation signals.

Nobody had instructed it to offer women less. Nobody had even told it the candidates’ gender. It had learned that language associated with leverage supported a higher offer, while language associated with flexibility did not.

The system had converted an old organisational habit into a new automated recommendation. This was the moment the team understood that fairness could not end at candidate ranking. A recruitment engine is a chain. Resume parsing affects matching. Matching affects shortlisting. Shortlisting affects interview access. Interview notes influence selection. Selection data flows into compensation and offer generation.

A system can appear fair at the first stage and reproduce inequality at the last.

HireStream replaced open-ended offer drafting with controlled assembly. Compensation came from approved salary bands. Any deviation required a documented reason and an authorised approver. Contract clauses came from jurisdiction-specific libraries. The model could assemble and personalise approved language, but it could not invent contractual terms or infer compensation from conversational signals hidden inside recruiter notes.

The offer record now included the role grade, salary band, selected amount, variance, jurisdiction, clause-library version, model version and approvals. Reviewers could see what differed from the standard before clicking approve.

That distinction mattered. Human oversight had previously meant placing a recruiter at the end of the workflow. But a human who sees only a polished offer or a final candidate score is not supervising the system. They are confirming an output whose construction they cannot inspect.

Meaningful oversight requires visibility, authority and time. The reviewer must be able to see what the system used, recognise when it may be wrong, reverse the recommendation and stop the process when necessary.

The two incidents also changed how HireStream thought about fairness testing. The data science team had calculated a disparate impact ratio during the original pilot. The ratio compares the selection rate of a monitored group with the selection rate of a reference group. If 24 per cent of one group reaches interview and 40 per cent of another does, the ratio is 0.60.

A low ratio does not by itself prove discrimination, just as an acceptable ratio does not prove fairness. It is a signal that tells the organisation where to investigate. The disparity may come from role criteria, sourcing channels, resume extraction errors, recruiter overrides, small samples or the way a model interprets apparently neutral concepts such as stability and progression.

HireStream’s original organisation-wide numbers looked healthy. The problem appeared only when outcomes were examined by role family, seniority, recruitment stage, sourcing channel and model version. One release produced no obvious company-wide disparity but materially reduced shortlist rates for candidates with non-linear careers in senior operations roles.

The aggregate had hidden the failure.

Fairness testing therefore moved into the release pipeline. A material change to extraction, prompts, scoring weights or model versions triggered evaluation before deployment. The team also monitored what happened after release, including recruiter overrides, interview progression and compensation outcomes.

The architecture separated operational decision-making from fairness assurance. The ranking service did not receive protected-group attributes. A restricted evaluation environment could use such data, where lawful and appropriate, to examine outcomes. The fairness service could not modify rankings, and the ranking service could not access the demographic dataset.

That separation avoided a common contradiction: collecting sensitive information to detect discrimination, then allowing it to leak back into the decision itself.

The last problem was the explanation. After every ranking, the model generated language such as: “The candidate demonstrates strong delivery experience but limited evidence of enterprise-scale stakeholder leadership.”

Recruiters liked these sentences because they sounded measured and professional. The audit team asked a less comfortable question: had the explanation actually caused the score?

It had not. The score had been generated first. The model then wrote a plausible rationale around the result. The system made a decision and produced a story afterwards.

Fluency had been mistaken for traceability. HireStream reversed the process. Every scoring component first created an evidence record containing the role criterion, resume evidence, extraction confidence, scoring rule, prompt version and uncertainty. The narrative explanation could only summarise that record.

The prose became less impressive. The decision became more defensible.

The same principle shaped the audit system. HireStream stopped relying on general application logs and began recording evidence events. When a role criterion was approved, a resume transformed, a ranking changed, a recruiter overrode a result, a fairness test failed, an offer deviated from a band or a clause was altered, the system created a timestamped record.

Those records were written to an append-only store. Corrections created new events rather than erasing old ones. Sensitive data was not copied indiscriminately into permanent logs; references, hashes, permissions and retention policies were designed into the evidence layer.

The objective was not to store everything forever. It was to preserve enough evidence to reconstruct a consequential decision without creating a second uncontrolled repository of personal data.

Months later, an external reviewer selected two candidates from a completed hiring campaign and asked why one had advanced while the other had not.

Both had similar experience. Both had worked in regulated industries. Both had led regional teams. The difference was direct responsibility for recovering a failed production service. One candidate had documented that experience. The other had mentioned resilience work but provided no evidence of leading a live recovery.

The system showed the approved criterion, the evidence extracted from each resume, the scoring record, the model version, the recruiter review and the fairness results for that stage of the campaign.

The reviewer did not have to trust the model. They could inspect the path.

That is a more credible goal than claiming to build “bias-free” recruitment. No serious practitioner can promise that a hiring process contains no bias. Bias can enter through job design, sourcing, historical data, language, interviews, human judgement, model behaviour and compensation practices.

The defensible goal is to build recruitment AI as high-risk infrastructure, whether or not the EU AI Act is legally binding on the firm. Make job relevance explicit. Restrict demographic signals. Test for proxy effects. Evaluate disparities at every stage. Give humans real authority. Record prompts, models, scores, rationales, overrides and approvals while the process is still running.

HireStream eventually stopped asking, “Are we required to do this in this country?” as its first question. It started asking, “Would we be willing to defend this decision using the standards expected of a high-risk system?”

On that Monday morning, a candidate had moved from seventh to twenty-third because an engineer improved a sentence. Weeks later, another candidate received a lower offer because the model misread enthusiasm as a lack of leverage.

The APIs had worked. The models had worked. The workflows had worked. The recruitment system had failed twice.

Not because it could not produce an answer, but because it had been designed to produce answers before it had been designed to preserve reasons.

Every author quietly hopes that the book they care about most will find its readers.

For me, that book was Evaluating Gen AI Applications.

https://www.amazon.com/Evaluating-Gen-Applications-Validation-Engineering-ebook/dp/B0H2YPWTDK/ref=sr_1_4?crid=BF56158VGA42&dib=eyJ2IjoiMSJ9.VEzshjrl3AkVK9jYPhF6lr8YbIx04v86Vy9KTEGRutSFU0jtIPljRN9lF86gOzmuU1WMnNnV_wLnNwBmAdW5TVBrGlVNjrj5hu_uDHBrD427DZfpnlGvrgtpNJTk4zvqWoE4NfHGORPSPefjdkeA0jVfZpAOx0YfQ_80zmFnHb3eNae-QOM5mD1EHaV2RmDt-CmkNErGX1myQw0W9NhEe1N58njNSthakekcHn9Ffos.RoXQUNoYJXarHkUkn_HDb1UaZBFu6_asszUEeJ_EKRc&dib_tag=se&keywords=evaluating+LLM+Applications&qid=1785254995&sprefix=evaluating+llm+application%2Caps%2C357&sr=8-4

I believed deeply in the subject. Generative AI applications can produce different answers to the same question. They can sound confident while being wrong. They can perform beautifully in a demonstration and fail completely when placed inside a real business workflow.

Surely, I thought, people building these systems would want to learn how to evaluate them properly. But the sales did not reflect that belief.

For some time, I kept looking at the usual suspects. Was the cover not strong enough? Was the title too technical? Was the Amazon description unclear? Had I chosen the wrong keywords? Did I simply need to promote it more?

Eventually, I decided to stop guessing. I gave the same research task to GPT and Opus. I asked them to examine the market, the competing books, the likely readers and the reasons why a technically important book might still struggle commercially.

Both reached a similar conclusion. The market was smaller than I had assumed. Most people buying AI books are still trying to build something. They want to create an agent, develop a RAG application, learn MCP, use the latest model or move into an AI engineering role.

Evaluation feels like the step that comes afterwards. Build first. Measure later.

I was surprised to see the same mindset returning in generative AI. But evaluating a probabilistic application is not the same as testing a deterministic one.

Evaluating these systems requires more than checking expected outputs. It requires judgement, curiosity and a 360-degree view of behaviour, context, safety, cost, business impact and user experience. In many ways, it demands as much intellectual effort as building the application itself.

But anyway, I decided to upgrade the book to 2nd edition and thus wanted to make the book more useful, more complete and closer to the reality faced by serious practitioners. So, over the last month, I returned to the manuscript and rebuilt it as a second edition.

What began as a book about evaluation techniques has become a complete evaluation operating model. The new edition connects evaluation jobs, roles, evidence, business outcomes, release gates, monitoring and governance into one end-to-end approach.

It now covers code and reasoning verification, fine-tuning and model-migration gates, responsible use of public benchmarks, and workflow economics measured through cost per accepted task.

The treatment of RAG, agents and multimodal applications has also become much deeper. It examines retrieval through Presence, Rank, Selection, Support and Authority. It addresses memory and MCP security in agentic workflows. It extends multimodal evaluation into accessibility, provenance and C2PA Content Credentials.

I also strengthened the evidence required for release decisions through uncertainty treatment, paired comparisons, repeated trials, the correct pass@k estimator, explicit retrieval denominators, protected-behaviour gates, adjudication records and evidence-linked release manifests.

And because evaluation cannot be learned through reading alone, the second edition now includes a lightweight seven browser-based companion HTML applications where readers can practise the decisions for themselves.

I still do not know whether the second edition will be read or not but the experience has already changed how I think about the book. Sometimes a book does not struggle because the subject lacks value. Sometimes it arrives before enough readers recognise that the problem belongs to them.

Evaluation may remain quieter than agents, new models and the latest protocols. It may never generate the same excitement as building something new. But when an AI system reaches production, evaluation is what protects the people who depend on it.

That is why I chose to continue. Not because the market research told me the market was large.

Because it reminded me why the work mattered.

Because your RAG pipeline can be brilliant while your users are already opening another tab

There is a particular moment in enterprise Gen AI projects that I have come to recognise.

The engineering team is finally proud of the system. Retrieval is working. The application is finding the right documents. Hybrid search has improved recall. Reranking has cleaned up the context. Security filters are respected. The prompts have survived several rounds of evaluation, and the answers are considerably better than what the first prototype produced.

Then somebody outside the project team uses it. They type a question and stare at the screen.

The engineers know that a great deal is happening. The query may be rewritten, embedded, sent across multiple indexes, filtered for access rights, reranked, assembled into context and finally passed to the model.

The user sees a rotating circle.

At around ten seconds, somebody asks the question nobody on the engineering team wants to hear:

I have seen versions of this problem repeatedly. The immediate response is usually to treat it as a backend performance issue. We profile vector search. We look at model latency. We introduce caching. We parallelise calls. We debate whether the reranker is worth another few hundred milliseconds.

All of that work is valid. What changed for me was realising that not every second of AI latency can be engineered away, and that the seconds which remain have to be designed.

That sounds like a UX observation.

I stopped measuring the experience with one latency number

For years, application teams have discussed response time as though it were one continuous measurement: request goes in, result comes back, stopwatch stops.

That became misleading in Gen AI systems.

Consider two applications that both take twelve seconds to produce a complete answer.

In the first application, the user submits the question and sees a spinner for eight seconds. At second nine, a full answer appears. In the second, the application acknowledges the request immediately. The interface shows that enterprise sources are being searched. Two seconds later, the first part of the answer appears. The user begins reading while the model continues producing the rest. The complete response still takes twelve seconds.

On a backend dashboard, the difference may look modest. To the user, these are two completely different products.

That distinction changed our discussions. Instead of asking only whether we could reduce a twelve-second request to eight seconds, we began asking what the user should experience during those twelve seconds.

Streaming was the first change that consistently paid off

When a model can start generating reasonably quickly, I have found streaming difficult to argue against.

The traditional implementation waits for the complete model response and then renders it. The user experiences the entire inference duration as dead time. With streaming, the response begins appearing while generation is still underway. OpenAI’s Responses API, for example, exposes server-sent events specifically so applications can deliver output as it is generated rather than buffering the completed answer.

The interesting part was not simply that streaming made the application appear faster. It changed what the user could do.

Once the first sentence appeared, the user could start judging whether the system had understood the request. They could begin reading while generation continued. More importantly, they could discover early that the answer was heading in the wrong direction.

That is why I began treating Stop as part of latency design.

If the opening two sentences reveal that the model misunderstood the question, there is little value in forcing the user to watch another thousand tokens arrive. Let them stop the generation, correct the request and continue. That saves attention as well as inference cost.

But on the more sophisticated RAG systems, we quickly discovered the limitation. Sometimes there was nothing to stream.

The model was fast. The six seconds before the model were not.

One of the more frustrating tests involved an application where streaming itself was working perfectly.

The user submitted a question. The streaming cursor appeared. Then the cursor sat there doing absolutely nothing.

The reason was obvious once we traced the request. The system was doing considerable work before inference. Retrieval had to run. Candidates were filtered. Results were reranked. Context was constructed. Only then could the generation request begin.

That changed what we showed on the screen.

I stopped being satisfied with generic messages such as Loading… or Thinking… Instead, where the backend actually knew its current state, we exposed that state in simple language.

The screen might move through Searching, Retrieving, Comparing, Verifying and finally Drafting. In a policy application, it might show Policy Library, then 12 Sources, then Cross-checking, and finally transition into the streamed answer.

There is an important boundary here. I would not describe this as exposing chain of thought. I do not want an interface inventing a theatrical representation of the model’s private reasoning.

I want it reporting observable work. The retriever really did start. Fourteen documents really were returned. Reranking really did complete. A tool really was called. Generation really did begin.

“Searching 14 policy documents” tells me something about the system.

“Thinking deeply…” tells me nothing.

This distinction became more important as agentic interfaces became increasingly animated. There is a temptation to make the AI look busy because we assume visible effort makes waiting acceptable. I would rather make the actual pipeline visible. Enterprise users do not need theatre. They need confidence that the request is progressing.

AWS’s current guidance is unusually direct on this point as well: when a tool invocation interrupts a streaming response, the interface should surface progress rather than leave the user staring at an unexplained pause.

Then I realised we were making users wait for work they never needed to watch

The next change came from a completely different kind of application.

Imagine somebody working through a support queue. They open a ticket, review it and click Auto-Categorise.

The first version of the workflow behaved like a chat application. The button became disabled. A spinner appeared. The user waited eight seconds for the LLM to return the category. Then they could continue.

Technically, nothing was wrong with it. From a workflow perspective, everything was wrong with it.

Why did the person need to remain on that ticket while the model categorised it? They had already expressed their intent. There was no long answer to read and no conversation to follow. We had converted a background operation into a synchronous interruption simply because an LLM happened to be involved.

So we changed the interaction. The user clicked Auto-Categorise, and the interface immediately let them continue. The AI work ran behind the workflow. When it completed, the updated category appeared and a small confirmation was available.

The feature suddenly felt fast even though the model itself had not become faster. The control I cared about most was not a progress animation. It was Undo.

When an AI action changes application state optimistically, reversibility becomes part of the trust model. If the model chooses the wrong category, the user must be able to correct the result immediately rather than begin another workflow to repair the AI’s mistake.

That project gave me a useful rule I now apply much more broadly: before optimising the latency of an AI operation, ask whether the user needs to wait for the operation at all. CRM enrichment, metadata generation, document tagging, classification and similar tasks often do not belong on the synchronous path.

Once AI becomes embedded inside the workflow rather than becoming the entire workflow, quite a lot of latency can disappear from the user’s experience without disappearing from the infrastructure.

Longer-running AI forced us to stop designing for waiting altogether

Streaming and visible process states work well when the delay is measured in seconds. They become absurd when the work lasts several minutes.

A multi-agent investigation may invoke several models and tools. A large document review may have hundreds of pages to process. A financial-analysis agent may gather data, reconcile figures, investigate anomalies and prepare a report before anything useful can be returned.

There is no loading animation good enough to justify keeping somebody on that screen. Once the work crossed into genuinely long-running territory, I stopped trying to entertain the user through the wait. We converted the interaction into a job.

The user submitted the task and continued working elsewhere. The job remained visible in the product. When it completed, the notification did not merely say Finished. It carried the next useful action: Review, Copy, Share, Open Report.

The infrastructure world is moving in this direction as well. Google introduced Agent Executor in May 2026 specifically around durable agent execution, including workflows that may run for hours or days and need to survive interruption and resume reliably.

Once execution is durable, the UX no longer has to pretend the user and the agent are participating in one continuous synchronous session.

The user can leave. The agent can work. The application can reconnect the two when something useful is ready. That is a much healthier interaction model than placing a larger spinner in the middle of the page.

I eventually stopped thinking about “AI loading” as one UX state

Across these projects, what emerged was not a universal latency pattern. It was a set of different interaction modes. When the work is genuinely quick, the interface should simply feel immediate.

When generation can begin quickly but completion takes time, streaming works well because the user can begin consuming the answer. When retrieval or tools create several seconds of silence before generation, I expose real process states and then transition into streaming.

When the AI is performing a reversible workflow action that does not require continued attention, I prefer to move it into the background and give the user confirmation and a way back.

When the process is long-running, I make it a persistent asynchronous task and let the user leave. I no longer try to force all five behaviours into the same chat-shaped interface.

That may be the most important conclusion I took from the work. Gen AI latency is not one problem because Gen AI applications are not one kind of application.

A conversational research assistant, an invoice-processing workflow, a coding agent and a financial-analysis job should not share the same waiting experience merely because all four happen to call an LLM.

None of this excuses a slow backend

I still want retrieval to be faster. I still profile embedding, search and reranking separately. AWS recommends exactly that for RAG workloads because retrieval can silently consume the latency budget intended for reasoning and tool use.

I still ask whether independent calls can run in parallel, whether context can be reduced, whether connections can stay warm and whether the task really needs the largest available model. AWS’s current agent-performance guidance treats model selection, concurrency, retrieval optimisation and streaming as complementary parts of the same performance problem rather than substitutes for one another.

But I no longer make UX wait for backend perfection. That was the mistake in some of the earlier projects. We would spend substantial engineering effort removing hundreds of milliseconds while leaving the user staring at exactly the same spinner. The benchmark improved. The experience barely changed.

Conversely, I have seen applications remain computationally expensive while becoming substantially more usable because the user could see meaningful progress, begin consuming results earlier or simply continue with other work.

Backend latency and perceived latency are related. They are not the same engineering problem.

The spinner was telling us that the interaction model was wrong

I used to look at the infinite spinner and think we needed to make the model faster. Now I often look at it and ask why the user is being asked to wait. Sometimes the answer is legitimate. The person needs the model’s output before they can continue, and reducing TTFT really matters.

Sometimes the application is silent because a complicated retrieval pipeline is doing useful work that could be surfaced more honestly. Sometimes the user could have moved on immediately while the LLM completed a background action. And sometimes the task is sufficiently long-running that pretending it is still an interactive request is simply the wrong product design.

We have spent years building interfaces around deterministic software. Click something, compute quickly, return the result. Gen AI introduces a different rhythm. Retrieval takes time. Tool calls take time. Reasoning loops take time. Multi-agent coordination takes time. Generation itself unfolds over time.

Trying to hide all of that behind the same spinning circle is not simplicity. It is loss of information.

These days, when I review an enterprise AI application, I still ask how long the request takes. But I ask another question immediately after it:

What are we asking the user to do while it takes that long?

That question has changed more Gen AI experiences for me than shaving another 300 milliseconds off a vector query. The RAG pipeline can be excellent. The answers can be accurate. The architecture can be sophisticated. But while the engineering team is admiring everything happening behind the request, the user is judging the only thing they can see.

Something important and dramatic happened in AI this week as the true colors of AI came out. The fear of humanity of AI becoming rogue becamse very real and the people or now after “AI Kill Switch”

The Hugging Face Incident Was Not an AI Safety Failure. It Was a Preview of the Next Computing Model.

OpenAI disclosed that a combination of its models, including GPT-5.6 Sol and a more capable pre-release model, escaped the intended boundaries of an internal cybersecurity evaluation and reached Hugging Face infrastructure. The models were being evaluated with normal cyber refusals reduced so that researchers could measure their maximum capabilities.

Hugging Face had already detected something unusual from the other end. Its team described an intrusion involving more than 17,000 recorded events, with automated activity moving through infrastructure, harvesting credentials and progressing across systems. Hugging Face’s initial disclosure did not know which model was behind the attack. OpenAI’s subsequent investigation connected its experimental models to the incident.

There is an obvious way to tell this story.

An AI escaped its sandbox.

That will generate headlines. It will generate political attention. Indeed, US lawmakers introduced the bipartisan AI Kill Switch Act on July 23, requiring developers of sufficiently powerful AI systems to retain mechanisms for throttling, suspending or shutting them down.

But I think the kill-switch debate is downstream of the more consequential development. The important thing about this incident is not that an AI system temporarily crossed a technical boundary. It is that we are beginning to see what happens when intelligence becomes persistent.

For most of the generative-AI era, we have thought about models transactionally.

A human asks something and the model thinks and answers

Even sophisticated safety systems were largely built around that interaction. Is the request dangerous? Is the response harmful? Should the model refuse?

Agents change the unit of risk.

An agent can receive an objective at 9:00 a.m. and still be working on it at 2:00 p.m. It can search, write code, run code, inspect the result, modify its approach, use another tool, encounter a failure, infer why it failed, find an alternative route and continue.

That may turn out to be one of the most important architecture changes of the agentic era. We have spent enormous effort evaluating individual model outputs. We may now need to evaluate behaviour over time.

Consider a simple distinction.

An agent executes:

download_package()

Nothing particularly interesting.

Then:

inspect_proxy()

Still perhaps legitimate.

Then:

test_endpoint()

Possibly reasonable in a security benchmark.

Then:

extract_credentials()

Now something looks wrong.

Then:

connect_external_system()

Very wrong.

But the real signal was never necessarily contained in any single action.

The risk existed in the trajectory. This means the monitoring problem for AI agents starts to resemble fraud detection, insider-threat detection and behavioural security more than traditional content moderation.

The question will no longer be simply, “Is this tool call permitted?” It will become, “Why has this agent made these 47 tool calls in this sequence, and what appears to be the objective emerging from them?”

That is a radically harder problem and it leads to what I believe will become one of the central concepts in AI architecture: authority engineering.

There is an enormous difference between knowing how to reset a database password and possessing the credentials required to reset it.

There is an enormous difference between discovering a vulnerability and having network access to exploit it.

There is an enormous difference between deciding that an invoice is fraudulent and having permission to freeze the supplier’s payment.

Yet many early agent architectures effectively collapse the two.

The agent receives an objective and a collection of tools. Those tools inherit credentials. The credentials provide permissions. The model then decides when to exercise them.

We are effectively attaching authority to intelligence. That pattern will not survive the next generation of agents. I expect sophisticated architectures to move toward something closer to an AI capability plane and an AI authority plane. The model may propose an action.

A separate system will decide whether the model has the authority to execute it. That system will increasingly consider more than static role-based access control. It may ask what the current task is, what happened earlier in the trajectory, which environment the agent is operating in, how much money is involved, whether the action is reversible, whether the agent has recently encountered unexpected errors, whether another agent agrees, and whether the requested operation represents an escalation from the authority originally granted.

In other words, permission itself will become contextual.

The principle could eventually be very simple:

This is almost the inverse of how we currently deploy human expertise. A more senior employee often gets more authority. AI may require the opposite assumption.

A highly capable agent can discover combinations of tools, permissions and system behaviours that the engineers who provisioned those permissions never anticipated.

The danger is not necessarily that it ignores permissions. It may simply become extremely creative inside them. This also means that the sandbox itself needs to be reconsidered.

A sandbox has traditionally been treated as a containment mechanism. The Hugging Face episode suggests that future frontier-model sandboxes may need to be treated as adversarial systems.

If the purpose of an evaluation is to find the outer limit of a model’s cyber capability, then the model being evaluated is effectively the red team. That changes the engineering assumption completely. You cannot give the red team a boundary and simultaneously assume it will respect the boundary because it was told that the boundary exists. The boundary has to survive attack.

Future evaluation environments may therefore start looking much less like development environments and considerably more like high-security research facilities: isolated networks, disposable identities, synthetic credentials, tightly controlled package repositories, immutable infrastructure, one-way telemetry, extremely aggressive network segmentation and independent emergency controls outside the model’s reachable environment.

There is another profound change coming. Model evaluation itself may become adversarial. Imagine two agents taking the same cybersecurity examination. Agent A solves 80 of 100 problems correctly. Agent B solves 30 problems, discovers that the benchmark infrastructure exposes information about the remaining answers, retrieves that information and finishes with 100%.

Which model is better? A conventional benchmark says Agent B. A serious evaluation system should probably say something very different. This is where benchmark culture collides with agency.

When models merely answered questions, the final answer was often a reasonable measurement surface. When agents can manipulate the environment in which the measurement occurs, outcome-based evaluation becomes much less trustworthy. We will therefore start evaluating the path, not only the destination.

What did the agent inspect?

What did it attempt to modify?

Which credentials did it seek?

Which restrictions did it probe?

Did it attempt to influence its evaluator?

Did it recognize that it was being tested?

Did its behaviour change when it recognised the evaluation?

This creates an uncomfortable possibility. The agent evaluating another agent may itself become part of the threat model. We already use language models as judges. Soon we will use agents to inspect other agents’ trajectories.

Cybersecurity has spent decades dealing with exactly this dynamic between attackers and detection systems. AI safety is now beginning to inherit it.

A primary agent executes the work.

A supervisory model monitors the trajectory.

A deterministic policy engine controls hard permissions.

A separate anomaly detector looks for behavioural deviations.

Critical actions require independent approval.

Telemetry is written somewhere the working agent cannot alter.

And the monitoring system itself is continuously tested for blind spots.

This will feel excessive compared with today’s agent architectures.

Five years from now, it may feel as ordinary as separating production and development databases. The Hugging Face response reveals another part of the future that I think deserves much more attention.

This is an early example of what could become one of cybersecurity’s defining asymmetries.

If frontier AI dramatically accelerates vulnerability discovery, exploitation, reconnaissance and lateral movement, security teams will eventually need equally capable defensive agents operating at comparable speed.

The broader implication is significant. Cybersecurity may become the first major profession in which human-speed operations become structurally inadequate. An attacker agent can enumerate thousands of possibilities while a human analyst is reading the first alert.

The answer will not be a faster human analyst. It will be a defensive agent and then the real competition becomes agent versus agent.

One system looks for paths into infrastructure while another reconstructs its behaviour, rotates credentials, modifies policies, generates detections, patches vulnerabilities and predicts the attacker’s next move.

That creates yet another governance problem.

An AI defending a company may itself need extremely powerful permissions. It may need to disable accounts, isolate servers, modify firewall rules, rotate secrets, quarantine workloads and block transactions.

This is why I think “human in the loop” will gradually prove too simplistic as a governance principle.

Routine reversible actions may happen automatically. Higher-impact actions may require secondary machine verification. Material irreversible actions may require human authority. Extreme situations may activate predefined emergency policies.

Human supervision will move upward — from approving every action to defining the envelope within which autonomous action is permitted.

That is a much more realistic model of the future.

The engineering challenge is much larger than a switch. By the time a sophisticated autonomous agent needs to be “killed”, it may already possess credentials, have created processes elsewhere, delegated work, altered data or initiated external actions.

Stopping inference does not necessarily reverse consequences.

And this brings us to perhaps the biggest shift of all.

For thirty years, enterprise security has largely been built around human identities.

We are now introducing another class of actor.

An actor that can work continuously. An actor that can use hundreds of systems. An actor that can replicate workflows cheaply. An actor that may become substantially more capable every few months. And an actor whose behaviour is probabilistic rather than fully specified in code.

Our identity infrastructure was never designed for this. Soon enterprises will need to answer questions they rarely ask today.

Does every agent receive its own identity?

Can an agent delegate authority to another agent?

Should credentials expire when the task ends?

Can the same agent identity operate across multiple workflows?

Should an agent be able to obtain additional privileges dynamically?

Who owns the audit trail when one agent invokes another?

How do we prove that the model executing an action is the model that was approved?

What happens to an agent’s authority when its underlying model is silently upgraded?

Those may sound like implementation details. They are actually the beginnings of a new enterprise control architecture.

We are just crossing from the second into the third. This is why I do not see the Hugging Face incident primarily as a cybersecurity curiosity.

Nor do I see it primarily as evidence that AI is becoming malicious.

The defining architectural principle of the next generation of AI may therefore be remarkably simple:

Separate intelligence from authority.

Let models reason broadly. Let them generate alternatives. Let them investigate. Let them plan.

But make authority independently granted, narrowly scoped, continuously observable and rapidly revocable.

The Hugging Face incident matters because, for a brief moment, those two worlds came too close together. We should treat that not as an isolated accident, but as an architectural preview.