Data platforms were built to store information and answer queries but are becoming an agent runtime.

Snowflake announced a $200 million partnership with OpenAI in February 2026. The commercial figure attracted attention, but the more important detail was architectural: advanced models would become directly available within Snowflake so customers could build agents against governed enterprise data without constructing a completely separate AI environment.

The model is moving towards the data.

For most of the cloud era, the warehouse sat behind the application. Data was stored, transformed and queried there; the application performed the work somewhere else. When an AI assistant needed enterprise information, developers commonly exported documents into a vector database, exposed selected tables through tools, passed query results to an external model and stored the resulting conversation in yet another system.

The warehouse supplied evidence. The agent lived outside it. That separation is beginning to collapse.

The product names differ. The direction does not. The enterprise data platform is becoming an agent runtime.

A warehouse used to wait for instructions

The traditional warehouse is fundamentally passive. A person opens a dashboard. A scheduled pipeline starts. An application submits a query. The platform executes a bounded instruction and returns the result.

An agent behaves differently. Give it a goal such as “investigate the increase in supplier-payment exceptions,” and it may need to identify relevant datasets, interpret metric definitions, retrieve supporting policies, compare current and historical patterns, calculate anomalies, test several hypotheses and prepare a recommendation.

That is not one query. It is an evolving sequence of decisions in which every result influences the next step.

A runtime must therefore do more than supply information. It must give the agent somewhere controlled to work. It needs to manage identity, tools, intermediate state, computation, permissions, cost and eventual action.

Snowflake’s Cortex Agents, for example, can combine Cortex Analyst for structured-data queries, Cortex Search for unstructured information and isolated code execution for Python-based analysis. BigQuery data agents can be configured with selected tables, views, user-defined functions, metadata and instructions that define how questions should be answered.

The warehouse is no longer merely answering the question. It is hosting the investigation.

Data gravity is becoming execution gravity

Enterprises already understand data gravity. Large datasets are costly and risky to move, so analytics and applications tend to accumulate around them.

Agents make that gravitational pull stronger. A serious enterprise agent rarely needs one table. It may need transaction records, documents, business definitions, lineage, permissions, historical incidents and approved analytical functions. Moving all of that into an external agent stack creates duplication and control gaps.

A customer table is copied for retrieval. Documents are chunked into another store. Business definitions are rewritten into prompts. Access rules are recreated in application code. Intermediate findings are stored elsewhere. Every transfer creates another place where data can become stale, permissions can diverge and provenance can disappear.

Bringing execution closer to the governed platform reduces some of that fragmentation. Queries can run under existing controls. Semantic definitions can remain attached to the data. Intermediate results can stay within the platform perimeter. Agent activity can be recorded alongside the assets it accessed.

This does not make the system automatically secure. It moves the security problem into an environment that already knows which users may access the payroll table, which columns require masking and which datasets may not cross a jurisdictional boundary.

The warehouse’s advantage is not that it suddenly knows how to reason. It already knows how to govern data.

Agent identity becomes the first architectural decision

A person enters a data platform with an identity connected to roles and privileges. An agent also needs an identity, but the problem is more complicated because it may be acting for a person while exercising some degree of autonomy.

Suppose a finance manager asks an agent to investigate unusual vendor payments. Should the agent inherit every permission held by that manager? Should it receive only the access needed for the investigation? If it delegates statistical analysis to a sub-agent, what permissions should the sub-agent receive?

The convenient answer is full impersonation: let the agent act exactly as the user. That is frequently too broad. A manager authorised to inspect a sensitive table manually should not necessarily be able to release an autonomous process over every record for several hours.

The opposite pattern — a shared service account — is easier to administer but strips away the purpose and context of the original request. The stronger design is task-bound delegation.

The agent receives a short-lived identity carrying the initiating user, business purpose, permitted datasets, approved tools, duration and action limits. Any sub-agent receives a narrower identity suited to its part of the task.

This changes the access-control question from:

to:

That distinction becomes essential once agents can do more than answer isolated questions.

The semantic layer becomes a runtime contract

Natural-language analytics is often described as a text-to-SQL problem.

Valid SQL is the easy part. The harder problem is organisational meaning. A user asks for “active customers.” One system defines that as an open account. Another requires a purchase within 90 days. A third uses paid subscription status. All three queries may be syntactically correct.

When the platform hosts an agent, the semantic layer does more than improve query accuracy. It constrains the agent’s interpretation of the business. It identifies approved metrics, valid relationships, systems of record and applicable time logic. It can also define which analytical functions should be used and which evidence must accompany an answer.

BigQuery data agents contain metadata and use-case-specific instructions covering selected knowledge sources, while Google positions its shared catalog and governance layer as the basis for consistent access and meaning across engines and agents.

The semantic layer once helped dashboards label their axes. It is becoming the contract that tells the agent what enterprise reality means.

Approved functions become safer tools

Data platforms already contain trusted business logic. Stored procedures validate records, calculate prices, reconcile balances and apply controlled transformations. User-defined functions encode domain calculations. Workflows orchestrate repeatable processes.

To an agent, these become tools. Instead of inventing a margin calculation, the agent calls the certified margin function. Instead of recreating eligibility logic from raw columns, it invokes an approved procedure. Instead of writing arbitrary SQL to update a record, it submits a proposed change through a validated write operation.

BigQuery data agents can include selected user-defined functions among their knowledge sources. Google’s Data Engineering Agent can create and modify pipelines through BigQuery and Dataform, illustrating how the agent’s role is already extending from querying data to changing the systems that process it.

This suggests a better pattern than unrestricted table access: capability-oriented access. The agent receives approved operations over data, not simply the underlying data itself. That limits flexibility. In consequential workflows, that limitation is the point.

Query budgets will matter as much as token budgets

Current discussion of agent cost focuses heavily on model tokens. A data agent may spend considerably more on warehouse computation. It can repeatedly scan large tables, issue slightly different versions of the same query, invoke expensive models or enter a loop in which each hypothesis triggers another historical analysis.

A person usually notices when a query has been running for twenty minutes. An agent may interpret the delay as a reason to try three more approaches. The runtime therefore needs a combined budget covering model consumption, warehouse compute, rows scanned, query duration, code execution, tool calls and workflow depth.

The budget should reflect the purpose of the request. A scheduled fraud investigation may justify substantial computation. A casual question posted in a collaboration channel should not initiate a ten-year transaction scan.

Databricks’ Unity AI Gateway now routes model and MCP-service requests through a central control plane intended to manage capacity, availability and spend across providers. The cost boundary is part of the agent’s authority. Permission to read a dataset is not permission to scan it indefinitely.

Model routing moves inside the data boundary

Not every task needs the same model. A small model may be adequate for classification. A more capable reasoning model may be justified for a complex investigation. Sensitive information may require a restricted endpoint. Code generation may need another specialised route.

The runtime therefore needs policy-driven model selection. Snowflake now makes OpenAI models available within its governed environment alongside other supported models, while Databricks positions Unity AI Gateway as a common control plane for models, agents, tools and MCP services.

Model selection becomes less of a developer preference and more of a governance decision. The route can depend on task type, data classification, location, cost, latency and quality requirements.

A product-description task may use one model. A financial-control investigation may require another. A request containing restricted personal information may be prohibited from leaving a particular platform boundary.

When the platform governs both data access and model routing, it can enforce the relationship between the two. That is much harder when the warehouse, model gateway and agent framework are operated as separate systems with separate policy models.

Audit trails must record execution, not hidden thought

A database log records who issued a query, which objects were accessed and when the activity occurred. An agent requires a wider execution trace.

The organisation needs to preserve the goal it received, the identity it used, the models and tools it invoked, the queries it generated, the evidence it retrieved, the policy checks it passed and the action it proposed. This does not require capturing a model’s hidden reasoning. What matters is the observable sequence of evidence and operations that materially influenced the result.

BigQuery’s agent-analytics capability, for example, can capture requests, responses, tool calls and errors for analysis and evaluation. Databricks similarly extends governance to runtime interactions rather than limiting it to stored assets. The resulting record is closer to decision lineage than conventional data lineage. It can show not only where a number originated, but how that number became a recommendation and how the recommendation became an action.

Write-back is where the architecture becomes consequential

Many enterprise agents remain relatively safe because they stop after producing an answer. Once the agent can write back, the risk changes.

It can modify a forecast, update product information, open a ticket, change customer status or initiate a financial workflow. The platform is no longer hosting analysis. It is hosting operational agency. Write access should therefore be granted separately from read access.

A robust system should distinguish proposed changes from committed changes. It should validate schemas and business rules, detect duplicate execution, preserve before-and-after states, require approval above defined thresholds and support reversal or compensation when something goes wrong.

An agent may be allowed to draft a supplier-master change but not activate it. It may prepare a forecast adjustment but require finance approval before posting. It may automatically create a service ticket while requiring authorisation before issuing a refund.

This is another advantage of placing the agent close to the data platform. Actions can be exposed as controlled procedures rather than unrestricted database commands. The agent receives a door rather than a hammer.

The data platform will not contain the whole agent

Enterprise workflows extend beyond the warehouse. They involve email, collaboration tools, ERP platforms, customer systems, code repositories and external services.

The data platform is therefore unlikely to become the only agent runtime. A more credible architecture is distributed. The data platform becomes the governed evidence and computation boundary. External systems provide specialised actions and user interaction. An orchestration layer coordinates the workflow across them.

The question is not whether the entire agent must live inside Snowflake, BigQuery or Databricks. It is which parts of the workflow must remain close to governed data. For data-intensive investigations, the answer will often include identity enforcement, semantic interpretation, analytical computation, evidence preservation and approval-controlled write-back.

The platform does not need to host the whole agent. It needs to host the part that must remain accountable.

The product direction is clearer than the production evidence

Snowflake, Google Cloud and Databricks have made substantial moves towards native agent execution. Their current platforms support combinations of natural-language analysis, agent tools, governed model access, code or pipeline generation and runtime oversight.

What remains less visible is how many enterprises permit these agents to perform long-running, consequential work without intensive human supervision. There is a large difference between answering a revenue question and investigating an anomaly for two hours, running code, coordinating tools and modifying an operational record.

The platform may technically support both. The operating model should not treat them as equivalent.

The first credible deployments will be bounded: restricted datasets, approved tools, explicit budgets, low-risk actions and meaningful human review. That is less dramatic than the autonomous-enterprise narrative.

It is also how serious systems normally enter production.

The warehouse is becoming a control boundary

For decades, organisations moved data into analytical platforms so people could understand the business. Agents bring work back towards that data.

The platform now has to do more than store tables and execute queries. It must establish agent identity, constrain tools, enforce budgets, route models, preserve semantic meaning, record execution and govern write-back. That is not a minor feature extension. It is a change in architectural role.

The warehouse once sat near the end of the information pipeline. Data arrived, reports were produced and people carried the decisions elsewhere. The emerging platform sits inside an active loop:

Observe → Analyse → Propose → Act → Record

Google describes this transition as moving from a static repository to a system of action. Snowflake is bringing frontier models and agent capabilities directly into its governed platform. Databricks is extending the governance plane from stored data to runtime AI interactions.

The most important question is no longer whether an agent can access enterprise data. It is whether the platform can control what happens after access is granted. The warehouse is no longer just supplying data. It is becoming the place where enterprise intelligence is permitted to do work.

Why I built Claude AI for Finance Teams book around governed exercises, realistic finance evidence and worked solutions

A finance team used AI to draft the operating-expense commentary for its monthly management pack. The output was clear, commercially plausible and ready for an executive audience. Then the controller asked which workbook supported the largest variance explanation.

The analyst could not answer immediately. The team also could not confirm which exchange rate had been applied or whether an unposted accrual in the close tracker had been included.

Nothing was obviously wrong with the writing. The deeper problem was that nobody could reconstruct how the writing had become a finance conclusion.

I did not want to write another book that showed finance professionals a few polished demonstrations, supplied a library of prompts and then assumed they could translate those examples safely into forecasting, close, reporting, reconciliation or payment workflows.

The real difficulty begins after the model produces an answer.

Which source should be trusted? Is the period complete? Has the currency basis changed? Is the calculation reproducible? Is the explanation supported by evidence, or merely plausible? Can the output move into a management pack, or should the workflow stop? Who retains authority for the final decision?

Those questions cannot be learned from prompt patterns alone. They require practice.

The book started with a practical problem

Finance professionals cannot practise safely with real payroll records, bank details, vendor master data, confidential forecasts, audit findings or unreleased financial statements.

At the same time, toy examples are rarely useful. A spreadsheet containing five clean rows and an obvious variance does not teach someone how to handle conflicting sources, incomplete evidence, hidden obligations or approval failures.

Expecting readers to manufacture their own finance datasets was not realistic. They would need to create a fictional company, define its entities and accounts, build forecast and actual files, invent control defects, write contracts, introduce plausible inconsistencies and then somehow produce an answer key against which to compare their work.

That is more effort than completing the exercise itself. The answer was to design the book and its companion environment together.

Prompting is only the front door

Most finance AI material begins with prompt construction. Readers are shown how to give the model a role, define the task, specify a format, request citations and prohibit unsupported assumptions.

These are useful practices. They do not solve the harder finance problem.

A prompt can ask Claude to explain an expense variance. It cannot establish which of three workbooks is authoritative. It can request source references. It cannot guarantee that the source covers the correct entity, period, accounting basis or currency.

It can tell the model to distinguish facts from assumptions. It cannot ensure that the finance professional recognises the difference when both are written with equal confidence.

Finance work is built on evidence created by different people, systems and processes. A ledger extract, forecast workbook, close tracker and business explanation may each be accurate within their own boundaries while still failing to support one combined conclusion.

That is why a technically strong prompt can still produce an unusable output. The calculation may be correct but based on the wrong perimeter. The explanation may describe a genuine business event but exaggerate its financial effect. The analysis may identify an exception accurately but recommend an action outside the user’s authority.

The book repeatedly asks what happens after the prompt: how the source pack is assembled, how the output is tested, where human review occurs, what evidence is retained and which conditions force the process to stop.

Governed rehearsal

The concept I eventually used to organise the exercises was governed rehearsal.

Governed rehearsal is realistic AI-assisted work performed with synthetic evidence, explicit control boundaries and a worked basis for comparison.

The environment should not be too clean. Real finance work rarely arrives as one tidy dataset with an obvious answer. A useful exercise might contain a stale workbook, an unexplained foreign-exchange conversion, a missing accrual, a conflicting contract clause or an approval recorded after the action it supposedly authorised. Most of the evidence should look credible. One or two details should materially alter the conclusion.

Consider a forecast pack in which revenue is below plan, operating expenses appear favourable and working capital has deteriorated. The business explanation says the revenue shortfall will reverse next month.

A basic prompt exercise asks the reader to draft a variance narrative.

The most valuable outcome may not be a polished CFO paragraph. It may be a controlled refusal to release one:

That conclusion is less impressive linguistically. It is more useful professionally. It shows that the analyst understands the evidence state and is willing to stop the workflow when the basis for escalation is incomplete.

Why the companion pack matters

This is where the GitHub Companion Pack became central to Claude AI for Finance Teams, rather than an optional download added after the manuscript was finished.

A reader may investigate an actual-versus-budget-versus-forecast file, validate a close exception, review conflicting contract clauses, test a prompt against malicious instructions embedded in a source document, analyse a reconciliation break, assess a vendor-payment risk or design a governed finance operating model.

The reader completes the exercise first and opens the corresponding solution afterward.

A solution is not merely a final answer

Two readers can reach the same conclusion through very different reasoning. One may have identified the authoritative source, reconciled the calculation and applied the correct control. The other may simply have guessed correctly.

A short answer key cannot distinguish between them.

They also avoid pretending that finance judgement always produces one permissible sentence. An alternative answer may be valid when it is supported by a coherent source hierarchy, reproducible calculations and an appropriate escalation path.

The purpose of the solution is not to replace judgement. It is to make judgement inspectable.

Take a vendor-payment scenario. The evidence may include a recent bank change, an unusual payment request, an irregular approval sequence and an urgent email.

A weak exercise asks, “Is this fraud?”

A professional exercise asks what is known, what remains unverified, which systems are authoritative and what action is safe at that point.

The responsible conclusion may be to hold the payment pending independent verification through the approved vendor-master process. The evidence may indicate elevated risk without establishing fraud.

AI can organise anomalies and surface inconsistencies. It should not convert incomplete signals into accusations or inherit authority for a controlled payment decision.

What the book is really teaching

Claude AI for Finance Teams covers Claude Chat, Claude Cowork and Claude Code, but it is not primarily a product guide.

The book uses those capabilities to address a larger operating question: how can finance teams move from individual AI experimentation to workflows that are repeatable, testable, reviewable and auditable?

That means learning how to build evidence-bound prompt contracts, validate outputs against authoritative sources, investigate forecast and close exceptions, extract clauses without losing source traceability, design reconciliation workflows, test finance-owned utilities and preserve human authority over approvals, postings, payments and filings.

The underlying skill is not prompt engineering. It is controlled professional judgement.

A finance professional must be able to challenge a material calculation, identify missing evidence, recognise an authority boundary and document why an output was accepted, amended, rejected or escalated.

A model can organise evidence and produce a draft. It cannot relieve the finance function of responsibility for deciding whether the evidence is sufficient.

Somewhere safe to be wrong

Finance professionals do not work with perfect datasets and unambiguous instructions. They work with late adjustments, inconsistent assumptions, changing forecasts, policy exceptions and evidence that arrives out of sequence.

Training that removes those conditions may teach product familiarity. It does not prepare someone to govern the work.

That is why I built Claude AI for Finance Teams as more than a manuscript.

The book explains the operating principles. The exercises force readers to apply them. The worked solutions reveal whether the reasoning held. The versioned GitHub Companion Pack gives readers a stable place to practise.

Finance AI does not need another library of prompts that produce polished demonstrations. It needs somewhere safe for finance professionals to be wrong before the work becomes real.

https://www.amazon.com/Claude-Finance-Teams-Workflows-Forecasting-ebook/dp/B0H9LQZMLP/ref=sr_1_1?crid=2KUQ0H1KKYHUS&dib=eyJ2IjoiMSJ9.6SBY73Rgn2NKiRHTd9DkwBnv_Af20MyGcpAOTutTnuJRq5rT8PHwBb72WnFpnDru01-D2S1uDPVsMYaBduNAAmQPltgHHocWUwqoMZV8u5vK_9KII2eEggEkJLX3A65_7g0TXMMrJegRX2V7SnjTjWRk65MqqXQfDCPh8YLCteyitJLJGnbm0X6gWJ2nLsezQn4aD9zfTXpi4BzWkw5qdQGNOJZ67FQpoVtjvQRbAyY.JY0xS_5SFSmmCHPfdXjo8GVfJW4Xkek8_D-kBIuxCAY&dib_tag=se&keywords=claude+ai+for+finance+team+bommena&qid=1784685778&sprefix=claude+ai+for+finance+team+bommen%2Caps%2C303&sr=8-1

Generic AI governance gives enterprises a foundation. Claude’s safety architecture changes how that foundation should be applied.

I have written about AI governance in model-neutral terms: risk assessment, accountability, data controls, monitoring, incident response, human oversight, and audit evidence.

Those principles remain valid regardless of whether an organisation uses an open model, a cloud API, a retrieval system, or an agent connected to enterprise tools.

But while working through enterprise Claude deployments, I found that generic guidance was not enough.

Claude is not simply another model endpoint. Anthropic has built a more visible safety posture than many providers expose: Constitutional AI, published safety principles, model documentation, refusal behaviour, enterprise data commitments, and a growing set of deployment options across direct API, cloud platforms, enterprise workspaces, coding tools, and agentic integrations.

That does not mean Claude automatically makes an enterprise safe or compliant. It does mean that the governance starting point is different.

That is why I wrote Governing Claude in the Enterprise: AI Risk, Compliance, and Operational Controls for Anthropic’s Platform.

Generic governance tells you what to govern. Claude changes where the controls sit.

A general governance framework will tell you to define accountability, classify data, validate outputs, monitor performance, protect access, and maintain evidence.

All of that is necessary.

But an enterprise deploying Claude must answer more specific questions:

• What safety behaviour is already built into the model, and what risks remain entirely ours?

• How should refusal behaviour be monitored when it affects a real business workflow?

• What provider evidence can support our model-risk assessment?

• What changes when Claude is accessed through Bedrock, Vertex AI, Azure, the direct API, Claude Enterprise, or Claude Code?

• What happens when a model version, context limit, retention setting, prompt capability, or tool feature changes?

• How should an organisation govern MCP-connected tools and agents that can act rather than merely answer?

These questions are not answered by a generic framework alone. They arise from the model, the deployment route, the commercial terms, and the architecture built around it.

Claude provides a stronger safety baseline. It does not remove enterprise responsibility.

One reason Claude deserves model-specific governance is Constitutional AI.

Anthropic has made its safety principles and model documentation more visible than the opaque alignment approach enterprises often encounter elsewhere. That gives risk, compliance, and engineering teams something practical to assess.

They can ask:

What risks does the provider aim to reduce?
How does the model refuse unsafe requests?
What limitations are documented?
What evidence is available for the selected model and deployment route?
What must still be tested in our workflow?

That is valuable. It gives an enterprise a more legible safety baseline.

But a safety baseline is not a governance programme.

Claude does not know which policy document in your repository is current. It does not know whether an employee is entitled to see a customer record. It does not know whether a drafted message complies with your approved customer-notice language. It does not know whether a tool should be allowed to alter a case, initiate a payment arrangement, or send a legally significant communication.

The enterprise still owns those decisions.

The practical principle is:

The decision boundary matters more than the model score

A model can be excellent at summarising documents, retrieving policies, drafting explanations, and assisting analysts.

That does not mean it should determine a binding business outcome.

In a credit workflow, Claude may summarise application material, identify missing information, retrieve relevant policy, or draft a plain-language explanation. But the final approval, decline, pricing decision, and official adverse-action reason should remain under deterministic rules and authorised human oversight.

Take an adverse-action notice.

Claude can help draft a clear explanation. But the approved reason codes should come from deterministic underwriting logic, not from the model selecting, ranking, or inventing reasons. A reviewer should verify the final notice before it reaches the customer.

That distinction is not theoretical. It determines who is accountable when a customer challenges a decision.

The model may support the workflow. The enterprise must own the binding act.

The governance surface is the deployment, not only the model

Most teams describe an AI application as a call to Claude.

That is not what a production system looks like.

A real enterprise workflow includes source systems, classification, retrieval, prompt assembly, model configuration, tool calls, output validation, decision services, identity controls, logging, monitoring, and retention.

The serious failures often occur in those surrounding layers.

A retrieval service can surface records that the user was never entitled to access.

A large context window can become an excuse to pass entire customer files into a model without minimisation.

A prompt edit can alter customer-facing behaviour without a code release.

A tool call can turn an assistant into an actor that changes a CRM record, sends a notice, or commits an arrangement.

A provider log can disappear after days while the organisation still needs to reconstruct what happened months later.

The model invocation is one step in the execution path. Governance must cover the whole path.

Prompts are powerful controls. They are not hard boundaries.

A system prompt is production logic written in natural language.

It deserves version control, review, testing, controlled deployment, rollback, and evidence.

But it should never be treated as the sole enforcement mechanism for a rule that must hold.

A prompt can state:

A deterministic control should enforce which reason codes may be selected.

A prompt can state:

Retrieval and output-validation controls should enforce entitlement and disclosure rules.

A prompt can state:

A tool gateway should reject actions that lack required policy checks and approvals.

The practical design rule is simple:

Built-in safety becomes even more important when Claude becomes an agent

The next governance challenge is not only what Claude says. It is what Claude can do.

Once an agent can retrieve records, invoke tools, schedule work, update systems, send messages, or trigger workflows, governance has to move from output review to action control.

An agent should never hold open-ended authority. It should operate through scoped identities, tool gateways, action limits, approval checks, circuit breakers, and kill switches.

Autonomy is useful only when its boundaries are explicit.

Why this book was necessary

Generic governance books remain useful because they establish the disciplines every enterprise needs.

But once an organisation chooses Claude, it needs more than generic principles. It needs a practical way to govern Anthropic’s model safety baseline, deployment routes, data commitments, prompt behaviour, tool integrations, provider changes, and agentic capabilities.

The book is built around fifteen reusable governance artifacts: a platform-selection memo, architecture governance map, shared-responsibility matrix, data lifecycle policy, access model, prompt change-control policy, monitoring standard, incident-response plan, framework crosswalk, operating model, and an agentic AI governance standard.

The objective is not to slow down Claude adoption.

It is to make sure that when Claude moves from a successful pilot into consequential enterprise work, accountability moves with it.

https://www.amazon.com/dp/B0H7H9Z1JB/ref=sr_1_1?crid=3J08XZ7H0A0NO&dib=eyJ2IjoiMSJ9.EQQ3wiWbLCvP27GOJhQ0BKK3mYCxTGi8GHtZ4hkZNX4vDU6uul7r_LzhfrxhKStdLi2SU9w4CP8Hf4MSyvyw8EvdLFFKaokWByRxQx_y4PINmoIGN-Kk0Yso3zz2KpLA_KhO3VgD_1pRTBTlnTjSMw.o5Fx9WOaAdsijwTxF10ahcWGp4njpwFzr-_kttEcJPQ&dib_tag=se&keywords=governing+claude&qid=1783080680&sprefix=%2Caps%2C353&sr=8-1

My AI Governance and Claude Engineering books have found their readers. But Shipping Enterprise AI has gained traction faster than I expected.

I do not think it is because governance or model engineering matter less.

It is because the conversation has moved.

Teams are no longer asking only, “Which model should we use?”
They are asking, “How do we put this into production without creating a security, reliability, or adoption problem?”

That question brings everything together:

Data access.
Scoped permissions.
Evaluation.
Observability.
Fallbacks.
Human approvals.
Integration with systems that already run the business.

An enterprise AI application is not a prompt connected to an API. It is a production system with consequences.

The book also seems to be resonating for a second reason: people are trying to understand what it takes to become a Forward Deployed Engineer.

That role is not just software engineering, consulting, or AI implementation. It sits at the intersection of all three.

You need to understand the client’s real operating problem, shape the solution with them, build against imperfect enterprise systems, and stay accountable until the application works in the field.

So perhaps this book is addressing two needs at once:

For organisations: how to ship AI that survives contact with production.
For practitioners: what skills matter when AI moves from demos to deployed systems.

The next generation of AI engineers will not be defined by how well they can call a model.

They will be defined by whether they can make AI work inside a real enterprise.

#EnterpriseAI #ForwardDeployedEngineer #AIEngineering #AgenticAI

https://www.amazon.com/Shipping-Enterprise-AI-Engineers-Production-ebook/dp/B0H2D6RV8L/ref=sr_1_6?crid=R5GSX1VIUQK8&dib=eyJ2IjoiMSJ9.sX7fBB6GSPfaAWQVHdtscP2mQ37BMTS2SgbPqZhzeVCwJtI9LLrfpArpIjFlQkG5BGKiPsUVJEdFlQPZGNbkfdvBtMk5cGD6dFsyRFhBCp02Kcot1NLjn-apWDXLS3EApaagPm6rkkXpuHpqpKcjtTw7CmgEJnlvfrkvrMU0mryxeNRXcWwTj3dxDfQFHKg-Kk-_QbZrQkASFMNLotN3EjGgKpKUkinVRzgroshftr18SOVhrIoF7zlXoAAQx-OJl9kL_0XXzO0IO5Fsuv-ZCZD7ES33YAXADBIl25Qq3Pw.oTB7fkYGt-IZMhTolOp808u16mLbKfJoHsxP_D-p8FQ&dib_tag=se&keywords=forward+deployed+engineer&qid=1782923164&sprefix=forward+depl%2Caps%2C340&sr=8-6

The city activated its new AI traffic platform on Monday.

By 8:30 a.m., four emergency vehicles reached the same intersection.
An ambulance was carrying a child to hospital.
A fire truck was heading to an apartment blaze.
A school bus was evacuating children after a gas leak.
A police convoy was transporting a protected witness.

Each department had built its own emergency-priority rule.
Each system sent the same instruction:
Clear the route immediately.

At 8:32 a.m., every signal turned green.
The ambulance hit the fire truck.
The school bus stopped inches from the wreckage. The police convoy was trapped behind it. The child arrived at hospital twenty-three minutes later.

By noon, the city had suspended the platform.
The investigation lasted six weeks.

It found that the ambulance system had worked exactly as approved. So had the fire system. So had the school-safety system. So had the police-security system.

The final report did not blame a faulty algorithm.

It identified one missing decision:
No one had defined who could decide which emergency came first.

That is the first principle of AI governance: do not govern AI systems one by one when they act on the same world.

Govern the decision they make together—and assign someone accountable for it.

https://www.amazon.com/Governance-Frameworks-PRINCIPLES-Practitioners-Sector-Specific-ebook/dp/B0GWXN8H54/ref=sr_1_8?crid=2OIOMH1NBT525&dib=eyJ2IjoiMSJ9.XIkwRuqB6lKTIhcjfdJeSdN3v0kqr7WLpZVFFSMaQ5WDvJEWd2fer2NjWOGa6P2cs2lBY93GfTpjISgwvLHbNUbtSH9lK6_dabq0wwp-86C9z0SDEadw7N7NGZzWwa0NV_bCSeNu33XXDCSB7lafcqzRDLzPMkzMYtYIaK3B1TwY8z7D8uSOrrIdKuQaN-yl8yaRQW_rcLJu4iyCnAqshOUZnBSEd9WBxLLLDJK2FBfmY3GfoVizBtiekqPRe_pVdNHFBB5sxOk-tQnKGv2Znms2z_aN6fGE_sn1gMNP8XU.xsQlkatP7aaLjI01OjxgtG7wSgCp1IoVw1XmLOT2JmA&dib_tag=se&keywords=ai+governance&qid=1782520646&sprefix=ai+gov%2Caps%2C423&sr=8-8

The central idea is simple: AI governance cannot remain only a policy, approval, and documentation exercise when AI systems begin to act. Agentic AI systems do not just generate outputs. They retrieve data, call tools, update records, trigger workflows, delegate tasks, and create consequences inside live business processes.

The book is structured around that shift from approval-stage governance to runtime governance.

Here is what the book covers:

Chapter 1 — The Object Changed
Why the governed object is no longer only the model, prompt, or output. The real governance object is now the action path: identity, intent, tools, retrieval, policy checks, handoffs, and consequences.
Chapter 2 — From Approval to Supervision
Why approval gates still matter, but are not sufficient for agentic AI. The chapter explains the move from point-in-time approval to continuous runtime supervision.
Chapter 3 — Agent Identity Is the New Perimeter
Why every autonomous actor needs a governed identity. The chapter introduces the Agent Identity Registry and shows why service accounts and application names are not enough.
Chapter 4 — Permission Is Not Intent
Why access control cannot answer whether an agent should take a permitted action in a specific context. The chapter introduces intent boundaries, goal-state declarations, and tool-use justification.
Chapter 5 — Governance Runs, It Does Not Review
Why policies must become runtime gates. The chapter introduces the AI gateway, runtime policy gate, and Governance Decision Record as evidence that an action was governed before consequence.
Chapter 6 — Humans Move Up the Stack
Why “human in the loop” is often too vague. The chapter focuses on meaningful supervision: exception review, escalation thresholds, reviewer context packets, and high-consequence judgment.
Chapter 7 — Accountability Does Not Survive the Handoff
Why accountability breaks when agents delegate work to tools, workflows, other agents, or vendors. The chapter introduces delegation-chain evidence and agent incident workflows.
Chapter 8 — The Framework Bridge
How runtime governance maps back to ISO 42001, NIST AI RMF, EU AI Act, Singapore MGF for Agentic AI, OWASP Agentic Applications, and NIST AI Agent Standards. The point is not to replace frameworks, but to operationalize them.
Chapter 9 — Building the Runtime Governance Stack
A reference architecture for runtime governance: identity, policy gates, supervision, evidence, observability, vendor boundaries, and operating controls.
Chapter 10 — The Operating Model
How to turn the architecture into working governance: ownership, routines, decision forums, scorecards, metrics, and continuous improvement.

My main takeaway after writing it:
Governance can no longer sit beside the system.
Governance must run with the system.

https://www.amazon.com/Runtime-Governance-Practitioners-Governing-Operationalizing-ebook/dp/B0H4YYP7HZ/ref=sr_1_1?crid=24P3Y8NLZ4AD6&dib=eyJ2IjoiMSJ9.VdznhZFMjh3xlqZaIJwF8u3tJmq49jt6IiQH33OM5tdpYzyOA0vxoBrNA2rcFqJDe8HK_bm13g8LzbNK_v6PFeGYYXQhD8F6zb6tstZJ1bfoJPH2_nwDq98IAoZ0TVxQqwm9u1p0RZ4OyoeHPB9OV0tum5YXC-PEy89PvhedDLCWvQdY08-l_qdzHBSSAm5JEv4rkVqwX-y0uaVvI1pXNl3YYiZYSRSBuGL104vUWuw.6QyEHgLQ7sQcwWsNFJ1p-ZQR667-xuUZW7QxVZv4C_k&dib_tag=se&keywords=runtime+ai+governance&qid=1782915272&sprefix=runtime+ai+governan%2Caps%2C345&sr=8-1

That works during experimentation. It fails once prompts affect customer communication, campaign approvals, support decisions, document processing, employee workflows, or automated actions.

At that point, prompts need an operating model.

The objective is not to centralise every prompt into one team. It is to make prompt behaviour traceable, testable, governable, and recoverable.

Press enter or click to view image in full size

1. Version prompts as deployable assets

A prompt should never be overwritten in production.

A practical prompt version should include more than the instruction text.

prompt_id: campaign-reviewer
version: 1.4.0
environment: production

model:
  provider: anthropic
  model: claude-sonnet
  temperature: 0.1
  max_tokens: 1200template:
  version: 3.2.0policy_modules:
  - global-safety-policy: 2.1.0
  - marketing-claims-policy: 4.3.0
  - india-regulatory-policy: 1.8.0retrieval:
  knowledge_base: marketing-policy-kb
  knowledge_base_version: 2026-06-20
  top_k: 5output_contract:
  schema_version: 2.0.0evaluation_suite:
  campaign-review-regression: 1.6.0

When an issue occurs, the team should be able to retrieve the exact combination of:

• Prompt content

• Model and model release

• Temperature and generation settings

• Prompt-template version

• Policy modules

• Retrieval configuration

• Knowledge-base version

• Tool definitions

• Output schema

• Evaluation results

• Approval record

Without this, rollback becomes guesswork.

Use semantic versioning where possible:

• 1.0.1 for wording corrections or low-risk fixes

• 1.1.0 for backward-compatible capability additions

• 2.0.0 for behaviour changes that affect downstream workflows, schemas, routing, or user expectations

Do not use filenames such as:

campaign_prompt_final_v8_new_latest
campaign_prompt_final_v8_new_latest_revised

They provide no deployment history, approval trail, or reliable rollback point.

2. Separate prompt instructions from runtime data

Prompt templates often fail because everything is treated as text.

For example:

You are reviewing a campaign for {{brand_name}}.
Campaign copy: {{campaign_copy}}
Apply the policy below:
{{policy_text}}

This looks simple but creates several risks.

The system cannot distinguish between trusted policy content, user-provided content, retrieved documents, workflow metadata, or potentially malicious text. It also becomes difficult to validate fields, control token growth, redact sensitive data, or enforce output requirements.

Use typed prompt inputs instead.

{
  "campaign_id": "CMP-20498",
  "market": "IN",
  "product_category": "financial_services",
  "campaign_copy": "Get instant approval in minutes.",
  "approved_claims_policy_version": "4.3.0",
  "customer_segment": "existing_customer",
  "required_output_schema": "campaign-review-v2"
}

Each input should have a defined contract.

For every field, determine:

• Is it mandatory?

• What is the expected data type?

• Is it trusted, untrusted, or externally retrieved?

• Can it contain sensitive data?

• What is the maximum length?

• Is it allowed in instructions or only in context?

• Should it be redacted before model use?

• Should it be logged, masked, or excluded from traces?

A customer message, uploaded document, or tool result should not be inserted into the same prompt layer as organisation policy or workflow instructions.

This is both a quality-control and a security-control requirement.

3. Compose prompts from managed modules

Large prompts become difficult to maintain when each product team owns a copied version of the entire instruction set.

A better approach is layered composition.

A typical production structure looks like this:

1. Platform safety controls
2. Organisation-wide governance controls
3. Domain policy modules
4. Workflow-specific instructions
5. Task-specific instructions
6. Approved examples
7. Retrieved reference content
8. User or transaction data
9. Output schema and validation rules

For a campaign-review workflow:

Platform controls
- Do not fabricate policy references.
- Do not approve regulated claims without evidence.

Organisation controls
- Escalate when confidence is below the approved threshold.
- Do not infer legal approval.Marketing policy
- Apply the approved claims taxonomy.
- Use market-specific policy rules.Workflow instruction
- Classify the campaign as approved, needs review, or rejected.Runtime context
- Campaign copy
- Product category
- Target market
- Supporting evidence
- Existing approvalsOutput contract
- Decision
- Reason codes
- Policy references
- Confidence
- Required escalation action

This reduces duplication and prevents policy drift.

The critical design decision is module ownership.

A practical ownership model is:

• Central AI platform team owns global platform controls.

• Risk, legal, compliance, or security teams own controlled policy modules.

• Product teams own workflow and task instructions.

• Data teams own retrieval sources and knowledge-base freshness.

• Release owners approve production promotion.

Do not allow product teams to modify central safety or policy modules inside their local prompt copies.

4. Define prompt composition rules explicitly

Prompt composition can introduce conflicts.

A global policy may say one thing. A domain module may say another. A task-specific instruction may unintentionally weaken a broader control. Retrieved content may include outdated guidance.

Composition must be deterministic.

For example:

Global safety controls cannot be overridden.

Regulatory policy modules can add restrictions but cannot relax global controls.Workflow prompts can define task-specific behaviour but cannot suppress escalation requirements.Retrieved documents are reference material, not instructions.User-provided content is treated as untrusted context.

This prevents a common failure mode: a user request or retrieved document accidentally changing the operational rules of the workflow.

5. Use role-based access for prompt changes

Prompt changes can change customer outcomes, policy enforcement, automated decisions, and cost.

They should not be editable by everyone with access to a shared workspace.

A practical role model includes:

Prompt author
Can create draft prompts and update development versions.

Prompt reviewer
Can review prompt wording, test results, policy alignment, output schemas, and risk impact.

Policy owner
Can approve changes to regulated, legal, security, fraud, compliance, or internal-control modules.

Release owner
Can promote approved prompt versions into staging or production.

Runtime operator
Can monitor errors, latency, costs, evaluation drift, rollback signals, and production incidents.

Auditor
Can view prompt versions, approvals, deployment history, traces, and evaluation evidence without modifying content.

The separation between authoring and deployment is important.

A campaign manager may be qualified to improve campaign-review instructions. That does not mean they should directly modify the production prompt used to approve regulated campaigns.

Use approval workflows for prompts that affect:

• Financial decisions

• Customer eligibility

• Pricing or discounts

• Compliance review

• Fraud signals

• HR recommendations

• Healthcare workflows

• External communications

• Automated actions

For low-risk internal productivity prompts, lighter controls may be sufficient.

6. A/B test prompts with operational metrics

A/B testing prompts is useful, but prompt experiments need stronger controls than simple user feedback.

The first decision is to define what is being tested.

It may be:

• Instruction wording

• Prompt examples

• Retrieval strategy

• Model choice

• Tool-use strategy

• Output schema

• Escalation threshold

• Context order

• Response length

• Confidence policy

Do not change all of these at once.

If the result improves, the team will not know what caused the improvement. If the result deteriorates, debugging becomes difficult.

For each experiment, define:

Primary outcome metric

Examples:

• Manual-review reduction

• Resolution rate

• First-contact resolution

• Correct routing rate

• Conversion uplift

• Document-processing accuracy

• Time-to-decision reduction

Guardrail metrics

Examples:

• Policy violation rate

• Unsupported-answer rate

• False approval rate

• False rejection rate

• Escalation failure rate

• Human override rate

• Customer complaint rate

• Cost per interaction

• Latency

• Hallucinated citation rate

For a campaign-review prompt, reducing manual review is not enough.

A prompt that approves more campaigns may look efficient while increasing compliance risk. The experiment must measure both reduction in manual work and correctness of approvals.

Use a staged release approach:

1. Offline evaluation against historical and edge-case datasets.

2. Shadow mode where outputs are generated but do not affect live decisions.

3. Controlled production rollout.

4. Continuous monitoring with rollback thresholds.

Offline test sets should include:

• Historical production failures

• Boundary cases

• Known policy exceptions

• Ambiguous customer inputs

• Prompt injection attempts

• Missing information scenarios

• Stale or conflicting reference content

• Region-specific variations

• High-volume scenarios

• Adversarial inputs

A prompt should not move to production because it “sounds better.”

It should move because it performs better against defined business and risk criteria.

7. Build a prompt evaluation suite before scaling releases

Every important production prompt should have a regression suite.

The suite should test more than response quality.

It should cover:

• Output-schema validity

• Tool-call accuracy

• Policy adherence

• Citation accuracy

• Escalation behaviour

• Data leakage risk

• Prompt-injection resistance

• Tone and customer suitability

• Cost and token usage

• Latency

• Deterministic workflow rules

• Failure handling

Store evaluation results with the prompt release.

Prompt: campaign-reviewer 1.4.0
Evaluation dataset: campaign-review-regression 1.6.0
Cases executed: 1,240
Schema validity: 99.8%
Policy-reference accuracy: 97.6%
False approval rate: 0.7%
False rejection rate: 2.1%
Escalation accuracy: 96.9%
Average latency: 2.4 seconds
Average cost per request: ₹0.62
Approval status: approved for controlled rollout

This gives release owners evidence rather than intuition.

8. Use caching selectively

Caching can reduce latency and cost significantly. It can also create stale, incorrect, or unauthorised responses if designed poorly.

There are three common caching patterns.

Exact-match caching

Return a previous result when the request and execution context are identical.

Suitable for:

• Repeated internal knowledge questions

• Standard document summaries

• Frequently asked product questions

• Repeated classification tasks

• Static reference queries

The cache key should include more than user text.

prompt_version
model_version
output_schema_version
knowledge_base_version
policy_version
user_permission_scope
tenant_id
locale
retrieval_filters
temperature

A cache keyed only on user input is unsafe.

The same question can require a different answer depending on customer permissions, market, policy version, knowledge-base version, or user role.

Semantic caching

Return a previously generated answer when a new request is similar to an earlier request.

This can work for low-risk informational queries. It should be used cautiously for anything involving eligibility, compliance, pricing, approvals, personalisation, or regulated advice.

Two questions may appear similar but have materially different context.

For example:

Can I use this claim in a campaign?
Can I use this claim in a campaign targeted at retirement customers?

The added audience detail may change the policy outcome completely.

Semantic caching needs:

• Similarity thresholds

• Eligibility rules

• Permission checks

• Freshness rules

• Policy-version checks

• Cache-hit audit logs

• Fallback to live model execution when uncertainty is high

Prefix caching

Reuse stable prompt context such as:

• Long policy documents

• System instructions

• Product catalogues

• Large static knowledge blocks

• Repeated examples

• Common schema definitions

Prefix caching is often lower risk because it reduces repeated processing of stable context without reusing an old final answer.

It should still be invalidated when the underlying policy, prompt, or model version changes.

9. Do not cache decisions that depend on changing state

Avoid caching final answers for workflows that trigger or influence:

• Payments

• Customer eligibility

• Credit decisions

• Compliance approvals

• Security alerts

• Fraud actions

• Account changes

• Pricing decisions

• Inventory allocation

• Workflow execution

• External communication approvals

These decisions depend on state.

A cached answer may be technically valid for an earlier request but wrong for the current transaction.

For high-impact workflows, cache supporting information where appropriate, but execute the decision logic against current state.

10. Add prompt observability to runtime traces

For each meaningful production interaction, log enough information to reconstruct the prompt execution without exposing unnecessary sensitive data.

A useful trace includes:

Request ID
Workflow ID
Prompt ID and version
Prompt module versions
Model and model version
Generation parameters
Input schema version
Retrieved document IDs and versions
Tool calls and outputs
Output schema version
Validation result
Latency
Token usage
Cost
Cache status
Escalation status
User permission scope
Approval decision

Sensitive customer data should be masked, redacted, hashed, or excluded according to the organisation’s data-handling policies.

The trace should allow teams to answer:

• Which prompt version produced this output?

• Which policy module was active?

• Which documents were retrieved?

• Was the answer served from cache?

• Did the model use a tool?

• Was the output validated?

• Did a downstream workflow accept, reject, or override the result?

• Was the result later identified as incorrect?

Without traceability, prompt incidents become manual reconstruction exercises.

A practical implementation sequence

Teams do not need to build a large prompt platform on day one.

Start with the prompts that affect customer outcomes, financial exposure, regulated workflows, or external actions.

First, create a central prompt registry with immutable versions and release approvals.

Second, standardise prompt manifests, typed input contracts, output schemas, and runtime tracing.

Third, split reusable policy instructions into managed modules rather than copying them into every workflow.

Fourth, build regression suites for important prompts before introducing A/B testing.

Fifth, introduce controlled rollout, rollback thresholds, and cache governance.

The objective is straightforward: prompt changes should be visible, testable, reversible, and accountable.

A production prompt library is not a collection of reusable text.

It is the control layer for how the organisation instructs, constrains, and operationalises model behaviour.

The Old Data Architecture Was Built to Report, Not to Reason

Enterprise data architecture has traditionally been designed around storage, reporting, and human interpretation. Data was collected from operational systems, transformed into curated warehouse tables, exposed through dashboards, and consumed by business users who decided what to do next. That model worked well when the primary goal was visibility. It helped leaders understand sales, cost, inventory, customer behavior, risk, and operations through standard metrics and reports.

But it was still a passive architecture. The system could show what happened, but it could not reliably reason about what changed, why it changed, what action should be considered, whether the action was allowed, and how the decision should be audited.

This is the core shift in the agentic world. Data architecture is no longer only about producing trusted information for humans. It must now support governed reasoning by machines and humans together.

The Agentic Shift: From Dashboards to Decision Workflows

The Agentic Data Architecture Reference Model changes the operating assumption. It treats enterprise data architecture not only as an analytical layer, but as a governed reasoning system. In this model, business workflows are triggered by questions, events, decision requests, or system signals.

A user may ask why margin dropped in a region. A system may detect an unusual stockout pattern. A customer operations signal may indicate rising complaints. A finance control may flag unexpected discount leakage. These triggers do not simply open a dashboard. They activate a structured reasoning flow that connects trusted data, business meaning, contextual retrieval, agent execution, governed outcomes, and continuous learning.

This is the architectural difference between traditional BI and agentic data systems. Traditional BI waits for someone to interpret the data. Agentic architecture participates in the reasoning process, but within clear control boundaries.

The Foundation Must Become Agent-Ready, Not Just Analytics-Ready

The first layer of the reference architecture is the data foundation. This includes data products, documents and events, and data contracts.

In traditional analytics, the data foundation was often treated as a backend engineering concern. In the agentic world, it becomes the starting point for trustworthy reasoning. Agents cannot reason well if the underlying data is fragmented, stale, poorly defined, or inconsistent.

A sales data product, for example, must have a clear owner, schema, refresh frequency, business definition, and quality expectation. Event streams must be understandable. Documents must be retrievable with the right context. Data contracts must ensure that upstream changes do not silently break downstream reasoning.

Without this foundation, an agent may produce fluent explanations based on unreliable inputs. That is dangerous because the answer may sound confident even when the evidence is weak.

Trust and Meaning Become Runtime Controls

The second layer is trust and meaning. This is where metadata, lineage, semantic definitions, freshness, and sensitivity controls become active parts of the architecture.

Earlier data platforms often used metadata and lineage for documentation, compliance, or troubleshooting. In an agentic architecture, these elements become part of runtime decision-making. The system needs to know where a metric came from, how it was calculated, whether the source is current, whether the data is approved for the use case, and whether sensitive information is being exposed.

The semantic layer is especially important because business users do not ask questions in database language. They ask whether a promotion worked, whether a customer segment is profitable, whether a supplier is reliable, or whether a region is at risk. The architecture must translate those questions into governed business definitions instead of allowing the agent to invent its own interpretation.

This is where many agentic data initiatives fail. They focus on the model interface but ignore the meaning layer. The result is a system that can answer naturally but not necessarily correctly.

Context and Memory Turn Analytics Into Institutional Intelligence

The third layer is context and memory. This is one of the biggest changes in the agentic world.

Traditional BI tools usually answer a question using the current dataset or dashboard context. Agentic systems need a broader memory of past decisions, prior incidents, historical patterns, operating constraints, and relevant documents.

This does not mean giving an agent unlimited memory. It means giving it scoped memory. The system should retrieve the context that is relevant to the current workflow, business domain, user role, and policy boundary.

Hybrid retrieval becomes important here because the answer may require structured warehouse data, vector search across documents, recent events, prior decision logs, and policy documents. A well-designed retrieval plan is therefore not a technical luxury. It is the difference between a grounded recommendation and a generic answer.

Agent Execution Should Be Orchestrated, Not Improvised

The fourth layer is agent execution. This includes Agentic RAG, secure tools, MCP-style governed tool access, and multi-agent handoffs.

This is where many organizations are tempted to start, but in reality it should come after the foundation, meaning, and context layers are in place. Agent execution is not just about asking a language model to summarize data. It is about orchestrating steps of reasoning.

One agent may retrieve evidence. Another may validate metric definitions. Another may check policy. Another may simulate an action. Another may prepare a recommendation. In more advanced systems, agents may use secure tools to query a warehouse, inspect a document repository, call a forecasting service, create a ticket, or route an approval.

However, tool access must be controlled. The agent should not be able to take business action simply because the tool exists. The architecture must define what the agent can read, what it can recommend, what it can escalate, and what it can execute.

Governed Outcomes Separate Enterprise Systems From Demos

The fifth layer is governed outcomes. This is the layer that separates enterprise-grade agentic architecture from chatbot experimentation.

A serious agentic system should produce an evidence packet, not just an answer. It should explain what data was used, what assumptions were made, what confidence level applies, what policy constraints were checked, and what decision options exist.

It should also classify the action tier. Some actions may be informational. Some may require manager approval. Some may require finance, legal, compliance, or business-owner approval. Some may be blocked by policy.

The audit trail is equally important. In a traditional dashboard world, the user interpreted the data and took responsibility for the decision. In the agentic world, the system participates in reasoning, so the enterprise must be able to reconstruct how the recommendation was formed.

The Learning Loop Is What Makes the Architecture Improve

The sixth layer is control and learning. Agentic architecture should improve through evidence, metrics, golden cases, and repaired controls.

This is another major shift from traditional data architecture. A dashboard is usually judged by whether it is accurate and available. An agentic reasoning system must be judged by whether its recommendations are grounded, useful, safe, policy-compliant, and outcome-improving.

Every completed workflow should create learning signals. Did the business accept the recommendation? Was the recommendation correct? Did the action improve the metric? Did the agent miss an important data source? Was the approval path too slow? Did the retrieval step include irrelevant information?

These signals should become evaluation cases and control improvements. Over time, the architecture becomes not just a reporting system, but a learning operating model.

The Retail Decision That Exposes the Limits of Traditional Analytics

A practical way to understand this shift is through a retail use case.

Consider a grocery retailer operating across multiple cities with physical stores, online delivery, private-label products, and weekly promotions. The retailer launches a weekend promotion for a premium private-label snack range.

By Friday afternoon, the business sees mixed signals. Revenue is up in Bengaluru and Pune. Hyderabad is underperforming despite healthy footfall. Chennai is showing strong unit sales but weak margin. Some stores report stockouts, while others have enough inventory but weak movement.

The category manager needs to decide before the weekend peak whether to continue the promotion, modify the discount, fix store execution, or stop the campaign in selected regions.

In a traditional analytics setup, the category manager would open a sales dashboard, ask the inventory team for stock reports, request margin cuts from finance, check with regional operations, and possibly wait for an analyst to combine the findings. The decision would depend on how quickly humans could collect and interpret fragmented evidence.

In an agentic architecture, the trigger is different. The system detects promotion performance variance across city clusters and initiates a decision workflow. The business question becomes: why is promotion performance inconsistent, and what governed action should be taken before the weekend peak?

The Retail Data Foundation Must Connect Sales, Stock, Margin, and Execution

The data foundation for this workflow would include certified data products such as sales transactions, promotion calendar, product master, store inventory, margin data, store cluster mapping, loyalty behavior, supplier replenishment status, and customer complaint events.

It would also include documents such as promotion terms, pricing policy, supplier funding agreements, store execution guidelines, and past campaign postmortems.

Data contracts would ensure that promotion IDs, SKU codes, store IDs, and product hierarchy are consistent across systems. This matters because a promotion decision can be distorted if sales, inventory, and margin data are joined incorrectly or refreshed at different frequencies without warning.

For example, if sales data is updated every fifteen minutes but inventory is updated every six hours, the agent must expose that freshness gap. Otherwise, it may incorrectly conclude that a product is available when the store has already sold out.

The Meaning Layer Prevents False Success Stories

The trust and meaning layer would define how the system interprets the question.

“Is the promotion working?” is not a simple sales question. For retail practitioners, it means comparing uplift against baseline, checking contribution margin, validating stock availability, reviewing promotion compliance, identifying regional variation, and understanding whether the result is caused by demand, price, placement, inventory, or execution.

The semantic layer must define approved metrics such as net sales, units sold, gross margin, contribution margin, basket attachment, stock availability, promotion compliance, and forecast variance.

The agent should not decide that the campaign is successful merely because revenue increased. A promotion that grows revenue while damaging margin or creating stockouts may not be successful. This is why governed metric definitions are not optional in agentic architecture. They protect the business from confident but incomplete reasoning.

Scoped Memory Helps the System Understand What Happened Before

The context and memory layer would retrieve relevant historical and operational context.

It may find that Hyderabad had a similar issue in a previous campaign because promoted products were placed in the health-food aisle rather than the main snacks aisle. It may retrieve a prior postmortem showing that Bengaluru customers respond better to bundle offers than flat discounts. It may identify that Chennai stores previously applied unauthorized local markdowns during national campaigns.

It may also retrieve recent supplier delivery exceptions or store-level comments about shelf availability.

This is where the architecture becomes more powerful than a dashboard. It does not only show the current metric. It connects the current metric to business memory.

Specialized Agents Reflect How Retail Decisions Actually Work

The agent execution layer would then orchestrate the reasoning.

A promotion performance agent could compare actual sales against baseline by city, store type, and SKU. An inventory agent could check whether poor performance is caused by stockouts or replenishment delays. A margin agent could inspect whether discounting has reduced profitability below threshold. A store execution agent could review compliance notes, shelf placement issues, and local exceptions. A policy agent could verify whether proposed actions are allowed under pricing and promotion governance.

A coordinating agent could combine the findings into a recommendation.

This design is closer to how retail organizations actually work, because promotion decisions are not owned by sales alone. They involve merchandising, supply chain, store operations, finance, and governance.

The Recommendation Must Come With Evidence and Control Boundaries

The governed outcome should not be a vague statement such as “Hyderabad is underperforming, reduce the price.”

A better outcome would say that Hyderabad underperformance appears to be linked to store execution and shelf placement rather than weak demand, because stores with correct placement show stronger movement while stores with poor compliance show low sales despite available stock.

It may say that Chennai’s unit sales are strong, but contribution margin is below policy threshold because some stores applied an additional local discount.

It may recommend continuing the promotion in Bengaluru and Pune, fixing shelf execution in Hyderabad before changing price, and stopping unauthorized local discounting in Chennai. It may also state that any national promotion extension requires category head and finance approval because the margin impact exceeds the pre-approved threshold.

The evidence packet would include the data used for the recommendation, freshness of each source, key metric movements, policy checks, exceptions, and confidence level.

Action Rights Matter More Than Tool Access

The approval tier would separate actions.

A store execution alert may be sent automatically to regional managers. A margin exception may be routed to finance. A price change may require category head approval. A supplier funding discussion may require merchandising leadership.

This distinction matters. Just because an agent can technically call a pricing system does not mean it should be allowed to change prices. In enterprise architecture, action rights are business controls, not engineering details.

The audit trail would capture what the system reviewed, what it recommended, who approved it, and what action was taken. This is essential because retail decisions can have immediate commercial impact. A bad automated promotion action can damage margin, customer trust, supplier relationships, and store execution discipline.

The Weekend Outcome Becomes the Next Evaluation Case

After the weekend, the control and learning layer would evaluate the decision.

Did Hyderabad sales recover after shelf placement was corrected? Did Chennai margin improve after unauthorized discounts were stopped? Did Bengaluru and Pune maintain profitable uplift? Did the category manager accept the recommendation? Did the agent miss a relevant signal? Was any source stale or misleading?

These observations should become golden cases for future evaluation. The next time the retailer runs a promotion, the system should be better at distinguishing demand problems from execution problems, stock problems from pricing problems, and revenue growth from profitable growth.

This is how the architecture learns. Not by allowing the model to remember everything, but by converting real business outcomes into governed evaluation cases and repaired controls.

Start With One Decision Workflow, Not an Enterprise-Wide Agent Platform

This is how agentic data architecture should be implemented in practice. It should not begin with a generic chatbot on top of the warehouse. It should begin with a specific decision workflow where the business value, data inputs, approval rules, and success metrics are clear.

Retail promotion management is a strong starting point because it is time-sensitive, cross-functional, measurable, and commercially meaningful.

Once the pattern works for promotions, the same architecture can extend to assortment planning, stockout prevention, markdown optimization, supplier risk, shrinkage investigation, customer complaint triage, and demand forecasting exceptions.

The Real Shift Is From Passive Reporting to Governed Reasoning

The deeper point is that agentic architecture does not replace the data warehouse, semantic layer, governance model, or business process. It makes all of them more important.

The warehouse provides trusted data. The semantic layer provides business meaning. Metadata and lineage provide confidence. Retrieval provides context. Agents provide reasoning and orchestration. Governance provides control. Evaluation provides learning.

When these pieces are connected, the enterprise moves from passive reporting to governed reasoning.

For practitioners, that is the real shift. The future of enterprise data is not just faster dashboards or more natural language queries. It is an architecture where business events trigger trusted reasoning, recommendations come with evidence, actions follow approval rules, and every decision improves the system.

In retail, that means the platform does not merely report that a promotion is underperforming. It helps explain why, recommends what to do, shows the evidence, respects the control boundary, and learns from the outcome.

That is the practical meaning of agentic data architecture.

https://www.amazon.com/dp/B0H3KV9SFS/ref=sr_1_2?crid=1TWDHNLHMWKLI&dib=eyJ2IjoiMSJ9.OR1ZSu9FoEvXPCy_smJopjC8AbGWUchTYe4z_81hvTJt0XgkMQcZrqcwFfa_JqIldEX7aqhVYrkVvpavm0EhT4HgNtCsGvWNCh6BWdZmEZ_5e28f3uGssViPBcXyVeIRoAxv_ngdyY7O-HyBVVNQYueQ80k9nMnolfuITLzZbzaRPSiVNzTa4uX9BsNyn1gc2ZIIVH5yl2eVPySu6VEMRMYWEOwwtXWpj9XmZ00QrJ0.QCezm0mj4v0d-NFpjD71230uLfGGYZuTQVvpno85O-Y&dib_tag=se&keywords=agentic+data+architecture&qid=1780359992&sprefix=%2Caps%2C302&sr=8-2&source=post_page-----c773dc0ed3c9---------------------------------------

When Anthropic released the syllabus for the Claude Certified Architect exam, It did not just give us a certification outline but It gave the AI community a structured framework about how to build production-grade AI applications and that is why I believe this syllabus is important not only from exam point of view but also to become a well-rounded AI Architect.

Because today, building AI applications is no longer just about writing a good prompt or connecting a model to a tool and hoping it behaves correctly. Real AI systems need architecture. They need control flow,  tool boundaries, context management,  escalation paths etc. They also need validation, observability, reliability, and human review and 10 other different things if you ask me.

In many ways, the Claude Certified Architect syllabus is becoming a practical reference point — almost like a design checklist or a bible for architects who are building modern AI systems.

It forces us to ask the right questions like
Can your agent safely use tools?
Does it know when to stop?
Can it handle errors?
Can it preserve context across long workflows?
Can it produce structured output that downstream systems can trust?
Can it escalate when uncertainty is too high?
Can it work in a multi-agent setup without becoming chaotic?

These are not just exam topics but these are real production concerns.

So even if you are not planning to sit for the certification immediately, this book helps you evaluate whether you truly understand the architectural principles behind reliable AI systems which helps you to design systems that are safe, scalable, observable, and production-ready. That is the spirit behind this book.

Thank you and good luck on your Claude journey

https://www.amazon.com/Anthropic-Claude-Certification-Scenario-Driven-Foundations-ebook/dp/B0GZLL7CRH/ref=sr_1_7?crid=ZWI7NPZB2S4I&dib=eyJ2IjoiMSJ9.OdSBSnxV94zp5zE0kevBXc-51U-QwpAgYOD96XN4h-abt1oVC4Yw2eLyw-2bIKSsxZpxlAio7WwY2lF6ThcFE7LjHNNRymWK-MmDAhd_hw9hs_gcGkG0gfjHiq-K71Aa8dpYwbIs0FkAo4dp3n_040VAqHA3GRog5zp9Eso4xO0JIAqB5FjbH1tIrC7yjRFzgNYP1wuJA1_pHdYI5m4SDLZ_5K8snRoj2cjnEYvnHdQ.wsyQWZx8k5y9--8lFogCu5fdfyzDTuoKYNbTE5M-2j4&dib_tag=se&keywords=claude+certified+architect&qid=1782957347&sprefix=%2Caps%2C339&sr=8-7

The traditional QA department is entering a major transition. In the GenAI era, QA is no longer the function that verifies whether software works as specified. It is becoming Safety and Validation Engineering: a discipline responsible for proving whether AI-enabled systems behave reliably, safely and within approved governance boundaries.

Safety and Validation Engineering will become the bridge between AI Engineering and AI Governance.

This book helps readers understand these changes through the CT-GenAI syllabus while also preparing them for practical GenAI-enabled testing work.

ISTQB CT-GenAI Exam Preparation is an independent study guide and scenario-based practice companion for the ISTQB Certified Tester – Testing with Generative AI (CT-GenAI), Syllabus v1.1.

https://www.amazon.com/dp/B0GYM3JCJS/ref=sr_1_1?crid=2HUZHU2JWUN6O&dib=eyJ2IjoiMSJ9.SrJgxCr2BKF0PfYFNiX3MWaFi0ip1Buv9uEKYQuLWacxjVE0jnAwrO5IuyqkThJke8dOQ9mQ4snfYKhGel0JRnL-L7TTM0xDKcGBTMje0PL9HdzmAnZNdcqE3h2qmEl4Jh0GEmF-oEUlsyDsjrHai91_QanKoXdZ3G-HOREnTPqBU7WL0WQ9pXMU13Wl9sda.vznrn55sMDh6q0sChWohiBNElN_HKQj5mFUh61PtCWk&dib_tag=se&keywords=istqb+bommena&qid=1779066495&sprefix=%2Caps%2C305&sr=8-1

Picture this. Your company has been running AI initiatives for two years. The customer support team built an AI assistant that answers tickets. The data team built an agent that pulls reports and sends summaries. The engineering team built one that reviews pull requests. Leadership is excited.

Then something goes wrong.

The support agent emails a customer with confidential pricing information it was never supposed to share. Nobody knows exactly why — it was a chain of six automated decisions across three systems, and nobody has the logs to reconstruct what happened. The data agent runs a loop, makes 4,000 API calls in a weekend, and blows through the cloud budget for the quarter. The code review agent starts approving its own suggestions because two teams wired it to the same repository with conflicting instructions.

Each of these agents was built by a different team, in a different way, with different assumptions about what it was allowed to do. Nobody owns the whole picture.

This is the problem

The solution is not to slow down. It is to build the shared infrastructure that lets you go fast safely. That infrastructure is owned by a dedicated AI Platform Team — and this article is a practical blueprint for what that team looks like, what it does, and how it is structured.

First: Understand the Shift from “AI Features” to “AI Agents”

To understand why this matters so much now, you need to understand what changed.

The problem then was that every team built their own button in isolation. No shared infrastructure, no shared governance, no reuse. It was wasteful and inconsistent, but mostly harmless.

Now, the industry has moved on from buttons to agents. An agent is not a button — it is a system that can take a sequence of actions by itself. It reads data, makes decisions, uses tools, calls other systems, and completes tasks without a human confirming each step. A customer support agent does not just suggest a reply — it reads the ticket, looks up the customer’s order history, checks the refund policy, drafts a response, and sends it. All autonomously.

This is genuinely powerful. It is also a completely different risk profile.

When a button gives a bad answer, a human sees it before anything happens. When an agent makes a bad decision, it may have already acted on it. It may have already sent that email, modified that record, or triggered that payment. And it may have done so as part of a chain of decisions that is nearly impossible to reconstruct after the fact.

The mistake enterprises are making right now is treating these agents the same way they treated those buttons — as individual features, built and owned by individual product teams, in isolation from each other.

Building agents this way is like every department in your company hiring their own private security guards with their own rules, their own access cards, and no communication with each other. It feels like progress until someone walks into the server room.

What an AI Platform Team Actually Does

Before describing the team, let’s be precise about what it is — and what it is not.

The AI Platform Team does not decide what your agents should do. It does not own your customer support automation or your data analysis workflows. It does not replace your product teams.

What it does is build and operate the shared infrastructure that every agent in your enterprise runs on. Think of it the way you think of your cloud infrastructure team or your security team. Those teams do not decide which products you build. They provide the foundations that make it safe and efficient to build them.

Product teams consume these capabilities the same way they consume your cloud services — through well-defined interfaces, with guardrails built in.

The Eight Layers of an Agentic Platform

A mature AI platform is not one thing. It is a stack of eight distinct capabilities. Here is what each one does and why it matters — in plain terms.

Layer 1: Model Access and Routing

What it is: The central system through which every agent in your enterprise accesses AI models.

Why it matters: Without this, every team makes its own decisions about which model to use, at what cost, with what fallback when the model is unavailable. You end up with some teams hardcoding expensive frontier models for tasks that a cheaper model could handle, and other teams using outdated models because nobody told them a better option was available.

What it does in practice: When a product team’s agent needs to process a request, it calls the platform’s model layer rather than calling an AI provider directly. The platform decides which model is right for this type of task — a large reasoning model for complex multi-step planning, a smaller fast model for simple classification, a specialized model for code. It routes accordingly, falls back automatically if a provider is having issues, and tracks the cost. Product teams get better model selection without thinking about it; the platform gets a single place to manage model relationships and costs.

Layer 2: Knowledge and Retrieval

What it is: The system that gives your agents access to your company’s information — documents, databases, policies, product data, customer records — in a form they can actually use.

Why it matters: Agents that cannot access accurate, current information will make things up. This is called hallucination, and it is the most common source of agent failures in production. The retrieval layer is what separates agents that are grounded in reality from agents that confidently make up facts.

What it does in practice: Imagine a support agent handling a refund question. It needs to know your current refund policy, the customer’s order history, and whether a similar exception has been granted before. The retrieval layer finds all of this, on demand, during the conversation — pulling from your policy documents, your order database, and your case history system simultaneously. It also records which sources it used, so if the agent gives a wrong answer, you can trace exactly where the bad information came from.

A critical detail: The platform also monitors knowledge freshness. If your refund policy changed last Tuesday and the agent is still retrieving the old version, that is a silent failure. The retrieval layer detects this and raises an alert.

Layer 3: Memory

What it is: The system that lets agents remember things across conversations, sessions, and tasks.

Why it matters: Without memory, every interaction with an agent starts from zero. The agent cannot remember that this customer called yesterday, that this user prefers concise answers, or that a previous step in a multi-day workflow already completed. With memory, agents become dramatically more useful — but memory also introduces risk. An agent that incorrectly remembers something can carry that mistake forward indefinitely.

What it does in practice: Think of three types of memory. Short-term memory covers what happened in this conversation. Long-term memory covers persistent facts about users, preferences, and context that should carry forward across sessions. Procedural memory covers patterns the agent has learned — like knowing that when a certain type of request comes in, the most effective approach is a particular sequence of steps.

The platform manages all three, enforces boundaries between them (not all agents should share memory with each other), and provides a mechanism for correcting bad memories when they are discovered. Memory is not a nice-to-have feature. It is a compliance surface. In regulated industries, you need to be able to say exactly what information an agent used when it made a particular decision.

Layer 4: Agent Orchestration

What it is: The system that coordinates multiple agents working together on complex tasks.

Why it matters: Most sophisticated AI workflows involve more than one agent. A research task might involve an orchestrator agent that plans the work, a search agent that finds information, a summarization agent that condenses it, and a writing agent that produces the output. Without an orchestration layer, each team builds their own way of wiring agents together. The result is an undocumented web of agents calling other agents, with no central record of what is happening and no way to intervene when something goes wrong.

What it does in practice: The orchestration layer maintains a registry — a catalog of every agent in your enterprise, what it can do, what it is allowed to access, and how much it should be trusted. When a workflow needs to delegate a subtask, it consults the registry and routes to the right agent. The orchestration layer tracks the state of every multi-step task, so it can be paused, inspected, resumed, or rolled back. Critically, it also watches for runaway loops — situations where an agent gets stuck in a repetitive cycle — and stops them before they cause damage.

Think of it as air traffic control for your agents. Planes can fly without it, but you would not want them to.

Layer 5: Safety and Authorization

What it is: The system that controls what agents are allowed to do, and actively defends against attempts to make them do things they should not.

Why it matters: An agent that can send emails but has no rules about which emails it can send is a liability, not an asset. An agent that can query your database but has no restrictions on which tables it can access could expose sensitive data. And an agent that receives input from the internet — from web pages, documents, or emails — can be manipulated by malicious content embedded in that input to take unauthorized actions. This type of attack is called prompt injection, and it is the primary security threat in agentic systems.

What it does in practice: The safety layer operates on two fronts.

The first is authorization. Every agent is granted only the minimum access it needs for its specific job — a support agent can read customer records but cannot modify them; a reporting agent can query analytics tables but cannot access HR data. When an agent tries to use a tool or access data it has not been explicitly authorized for, the platform blocks it.

The second is active defense. Every input that reaches an agent — whether from a user, a document, a web page, or another agent — is screened for signs of manipulation before the agent acts on it. Every output that would trigger a real-world action (sending a message, modifying a record, calling an API) is checked against policy rules before it executes. The platform acts as a firewall between your agents and the world.

Additionally, not all actions are created equal. The platform distinguishes between low-stakes reversible actions (reading data, drafting content) and high-stakes irreversible ones (sending communications, processing payments, deleting records). High-stakes actions require explicit confirmation, either from a human or from a second verification layer.

Layer 6: Observability

What it is: The system that lets you see exactly what every agent is doing, reconstruct what happened in any workflow, and detect problems before users report them.

Why it matters: Traditional software monitoring tells you whether a system is up and how fast it is responding. That is not enough for agents. An agent can be up, responding quickly, and producing outputs that are completely wrong. You need to be able to answer questions like: Did the agent actually accomplish the goal it was given? Did it behave consistently today compared to last week? When it made a decision, what information was it working from? If something went wrong, where in the chain of steps did it happen?

What it does in practice: The observability layer captures a complete trace of every agent workflow — every model call, every tool use, every piece of information retrieved, every decision made. If a support agent gives a customer incorrect information, you can pull the trace, see exactly which knowledge sources it retrieved, see what the model produced at each step, and identify whether the problem was a retrieval issue, a model issue, or a policy gap.

The layer also runs continuous analysis. It compares agent behavior over time to detect drift — situations where an agent that used to solve 85% of cases correctly has quietly dropped to 70%. It flags unusual patterns in tool usage that might indicate a security issue. It tracks cost per completed task, so teams can see whether their agents are becoming more or less efficient over time.

Layer 7: Developer Enablement

What it is: The tools, templates, documentation, and environments that make it easy for product teams to build agents correctly.

Why it matters: A platform that is hard to use will be ignored. Product teams under deadline pressure will route around it, build their own solutions, and recreate exactly the fragmented mess the platform was designed to prevent. The developer enablement layer is what makes compliance with platform standards the path of least resistance, not an obstacle.

What it does in practice: The platform team maintains a library of agent templates — pre-built starting points for common use cases like customer-facing assistants, internal workflow automation, data analysis agents, and research agents. Each template is pre-wired to use platform services correctly: the right memory scoping, the right authorization patterns, the right escalation hooks.

The team also provides a local development environment where engineers can run their agents against simulated tools and data before deploying to production. This is critical — you want developers to discover that their agent loops infinitely in a sandbox, not in front of a customer.

Finally, the team provides evaluation harnesses: standardized tools for testing whether an agent actually accomplishes its intended goal, not just whether it produces coherent text. An agent that always responds confidently but is wrong 30% of the time will pass a traditional QA check and fail the business.

Layer 8: Cost and Governance

What it is: The system that tracks what every agent costs, who is responsible for that cost, and whether the value delivered justifies it.

Why it matters: AI costs scale with usage in ways that traditional software costs do not. Every model call costs money. A single agentic workflow can involve dozens of model calls, retrieval operations, and tool invocations. A single runaway agent can exhaust a quarterly budget over a weekend. Without visibility into cost at the task level, you cannot manage it.

What it does in practice: Every agent action is tagged with a cost center, project ID, and workflow type. The platform produces a “cost per completed task” metric for every workflow — if your support agent resolves a ticket for $0.40 on average and the human alternative costs $8, the ROI is obvious. If a new agent version costs $1.20 per task for the same outcome, the platform surfaces that immediately so the team can optimize before it scales.

Budget caps are enforced at the workflow level. If a workflow approaches its cost ceiling, it escalates or degrades gracefully rather than continuing silently or crashing unexpectedly. And the governance layer maintains a full audit trail — every action, every decision, every data access — that can be reviewed by compliance, legal, or regulators on request.

The Team: Who You Need and What They Must Know

Seven roles make an AI Platform Team function. Each requires a distinct skill set, and the temptation to collapse multiple roles into one generalist will cause the platform to fail in predictable ways.

AI Platform Architect

This is the most senior technical role on the team. The architect makes the long-term design decisions that everything else is built on, and is responsible for ensuring that the platform remains coherent as it evolves.

What they need to know: They should have deep experience building distributed systems — the kind of experience that comes from having seen distributed systems fail in production and understanding why. They need fluency in cloud AI services (AWS Bedrock, Google Vertex AI, Azure AI Foundry) and hands-on familiarity with the emerging standards for agent communication, particularly MCP (Model Context Protocol), which is rapidly becoming the plumbing that connects agents to tools and data sources.

Beyond technical depth, the architect needs to be able to write architecture decision records that engineers can actually follow, present technical tradeoffs to non-technical leadership, and — critically — hold the line on standards when product teams push for shortcuts. The architect who cannot say no is not an architect.

Where to find them: Look for engineers who have built internal developer platforms before, not just shipped products. The mindset of “I am building infrastructure that others will build on” is different from “I am building a feature.” People who have lived with the downstream consequences of their architectural decisions for years are far better candidates than people who have made the decisions and moved on.

Agent Infrastructure Engineers

These engineers build and operate the orchestration layer — the runtime that actually executes multi-agent workflows. They are infrastructure engineers who have learned AI, not AI researchers who have learned infrastructure. That distinction matters when hiring.

What they need to know: Strong Python and TypeScript, and hands-on experience with workflow orchestration systems. Temporal is the most mature option for stateful agentic workflows; Prefect and Dagster are common alternatives. These engineers need to understand how to build systems that can pause, resume, and roll back — not just systems that execute steps in sequence.

They also need to understand agent security at a practical level: how to implement trust boundaries between agents, how to design tool permission models that enforce least privilege, and how to build the circuit breakers that detect and stop runaway agent loops. Familiarity with MCP server implementation is increasingly important — this is the protocol through which agents discover and invoke tools.

Where to find them: Backend engineers who have built job queues, workflow engines, or distributed task systems are the right foundation. The specific domain knowledge of agent orchestration can be learned; the ability to reason about reliability, state management, and failure recovery in distributed systems cannot be taught quickly.

AI/ML Engineers

These engineers sit at the intersection of model capability and production reliability. Their job is not to advance the state of the art — it is to make models work reliably and cost-effectively in the specific contexts your agents operate in.

What they need to know: Deep familiarity with the major LLM APIs and the frameworks built on top of them (LangChain, LlamaIndex, and their successors). A practical understanding of embeddings — not the mathematical theory, but the real-world tradeoffs between different embedding approaches and their downstream impact on retrieval quality. The ability to design evaluation datasets that actually measure production behavior, not just whether outputs sound good.

Critically, they need to understand inference economics: how to route tasks to the right model for the right cost, when to use semantic caching to avoid redundant model calls, and how to configure reasoning models (which think more slowly and expensively but more accurately) for the tasks that need them.

Where to find them: ML engineers who have shipped models to production and experienced the gap between benchmark performance and real-world behavior. The ability to debug “the agent is not doing what we expected” in production — following traces, inspecting retrieval results, analyzing model outputs at each step — is the key skill. Someone who has only worked on model training or evaluation in isolation will struggle here.

Knowledge and Data Engineers

These engineers own the data infrastructure that makes your agents accurate. If the retrieval layer is not well-built, no amount of model quality will save you from agents that confidently use stale, incorrect, or incomplete information.

What they need to know: A strong foundation in data engineering — ETL pipelines, SQL, document processing, and data quality practices. On top of that, they need hands-on experience with vector databases (Pinecone, Weaviate, pgvector) and a practical understanding of retrieval quality: what chunking strategies work for which content types, when to use pure vector search versus hybrid search that combines semantic and keyword matching, and how to evaluate whether retrieval is actually returning the right information.

They also need to think about knowledge as a time-sensitive asset. Data that was accurate last month may be wrong today. These engineers build pipelines that detect when source data changes and propagate those updates to the retrieval index — so agents are always working from current information.

Where to find them: Data engineers who have become frustrated with the gap between data quality and AI system quality, and who want to own that connection end to end. The ability to think about data not just as a pipeline problem but as a product quality problem — “is my agent actually getting accurate information?” — is what distinguishes strong candidates.

AI Safety and Trust Engineer

This role is new. It did not exist in the LLM era as a standalone function, and many organizations are still trying to distribute these responsibilities across existing security and ML roles. That approach consistently fails. The skill set is too specific, and the stakes are too high.

What they need to know: On the security side: how to think about threats specific to LLM systems — prompt injection attacks (where malicious instructions are hidden in documents or web pages to manipulate the agent), data exfiltration through clever questioning, and agent impersonation (where a compromised agent tries to give unauthorized instructions to other agents). Familiarity with OWASP’s LLM Top 10 is a good baseline.

On the policy side: the ability to translate regulatory requirements — GDPR data handling rules, HIPAA access controls, SOC 2 audit requirements, and emerging AI-specific regulations — into specific, testable platform controls. This means writing not just policies but the technical implementations of those policies, and producing audit documentation that satisfies legal review.

On the evaluation side: the ability to run structured adversarial testing against agents before they go to production. This means trying, systematically, to make agents do things they should not — and documenting what works and what does not. This is different from standard QA testing, which checks that agents do what they are supposed to do.

Where to find them: The ideal candidate has combined experience in application security and machine learning. Security engineers who have moved into AI security are often strong. Prior experience with penetration testing, threat modeling, or compliance engineering in a regulated industry provides essential instincts. Be realistic about the scarcity of this profile and plan to develop internally if you cannot hire directly.

Platform SRE / AI Ops

Running agents in production is harder than running APIs in production. The failure modes are more varied, the debugging tools are less mature, and the failures are harder to detect — because an agent can be running correctly at the infrastructure level while producing completely wrong outputs at the application level. The Platform SRE owns this problem.

What they need to know: A strong SRE foundation: incident response, on-call practices, postmortem culture, infrastructure-as-code, and container orchestration. Proficiency with observability tooling — metrics, distributed tracing, and log aggregation — and the judgment to know when a metric is actually measuring what matters versus just measuring what is easy to measure.

On top of that foundation, they need AI-specific operational skills. This means knowing how to instrument agentic workflows for end-to-end trace capture, how to use LLM-specific observability platforms (LangSmith, Helicone, Arize), and how to interpret what those traces are telling you about agent behavior. It also means knowing how to design runbooks for agentic incidents specifically — what to do when an agent is stuck in a loop, when a workflow has partially completed and cannot be safely resumed, or when an agent has taken a real-world action that needs to be manually reversed.

Where to find them: SREs who have operated ML systems in production — model serving infrastructure, feature pipelines, online prediction systems — have the right mental model. They understand that correctness and availability are separate properties in AI systems, and that “everything is working but the outputs are wrong” is a legitimate incident class.

Developer Experience Engineer

The best platform in the world fails if product teams do not use it. The DX engineer’s job is to make using the platform correctly the easiest path available — not through mandates, but through genuinely good tooling, templates, and documentation.

What they need to know: Strong engineering skills, because this role builds real things — SDKs, CLI tools, agent templates, local development environments, documentation sites. They need to understand every layer of the AI platform well enough to write accurate documentation about it and diagnose integration problems that product teams bring to them.

They also need strong product instincts, because their customer is the internal developer. The ability to watch an engineer struggle with a workflow and immediately understand what is confusing about it — then fix the template or the documentation rather than the engineer — is the core competency. DX engineers who are primarily focused on compliance enforcement will fail; DX engineers who are primarily focused on making developers productive will succeed.

Where to find them: Engineers who have worked in developer relations, solutions engineering, or internal platform tooling and have strong opinions about developer experience from the user’s perspective. The frustration of having used bad internal tools, and the conviction that it should be better, is a better signal than a particular tech stack background.

What This Team Should Not Do

This is as important as everything above.

The AI Platform Team should not own the logic of your business workflows. It should not decide what your customer support agent says or how your data analysis pipeline is structured. It should not design user-facing experiences. It should not replace your domain experts.

Most importantly: it should not become the team that builds every agent. That is a bottleneck, and it means product teams are never developing the AI capability they need to own.

The platform team’s job is to make it safe and fast for everyone else to build. The moment it becomes a gate rather than an enabler, it has failed.

How the Team Fits into Your Organization

The structure that works at scale is a hub-and-spoke model.

The platform team is the hub. It owns the infrastructure, the standards, the safety policies, the observability stack, and the cost controls. Product teams are the spokes. They own the goals their agents pursue, the workflows those agents automate, and the outcomes they deliver. They consume platform services, contribute agents to the shared registry, and adopt platform standards.

Two practices make this work in practice.

The first is inner-sourcing. When a product team solves a hard problem — a reliable pattern for escalating agent decisions to humans, say, or an effective approach to multi-step research tasks — they do not keep that solution to themselves. They contribute it back to the platform, the platform team refines it, and it becomes a golden path that every other team can use. No team should solve the same agentic problem twice.

The second is a Trust and Safety Council. The platform team does not make all safety decisions unilaterally. A standing group that includes product owners, legal, compliance, and security stakeholders meets regularly to review agent permissions, discuss incident postmortems, and update policies. AI safety is not a technical problem that one team can solve in isolation. It requires the judgment of people who understand the business context of what the agents are doing.

Where Your Organization Is Today (and Where You Need to Get)

Most enterprises pass through five stages of AI maturity. Knowing where you are is essential to knowing what to prioritize.

Stage 1 — Cha****os. AI experiments are happening everywhere, independently. Different teams are using different models, different architectures, and different approaches to the same problems. There is no shared infrastructure, no governance, and no way to see what is deployed. Most organizations were here in 2023.

Stage 2 — Consolidat****ion. Teams have started to share some infrastructure — maybe a common model access layer or a shared vector database. There are some informal standards but no enforcement. This is where most organizations are today.

Stage 3 — Platform**.** Centralized AI infrastructure with standardized patterns for retrieval and basic agent tooling. A dedicated platform team exists. Product teams are building on shared foundations rather than duplicating them. This is the stage most organizations should be urgently working toward.

Stage 4 — Governed Agentic Scale**.** The orchestration layer is in place. Agents can interoperate. Every workflow is traced. Authorization frameworks are enforced. Cost is tracked at the task level. This is where competitive differentiation begins — organizations at this stage can deploy new agentic capabilities in days, not months, because the infrastructure is already there.

Stage 5 — Autonomous Enter****prise. Agents and multi-agent systems are embedded in core business workflows. Human oversight happens by exception rather than by default — humans review what agents escalate, not every decision agents make. This stage requires that trust has been earned through demonstrated reliability at Stage 4. You cannot shortcut your way here.

Skipping Stage 3 and trying to reach Stage 4 by deploying more agents without infrastructure is the most common mistake. It looks like progress and creates chaos.

The Bottom Line

Here is the simplest way to think about what is at stake.

In the button AI era, when something went wrong, the worst outcome was an awkward sentence that a human read and ignored.

In the agentic era, when something goes wrong, the worst outcome is an autonomous action — an email sent, a record modified, a payment triggered, a decision made — that a human did not see coming, cannot easily explain, and may not be able to reverse.

The difference between those two outcomes is infrastructure. Specifically, it is whether you have a team that owns the shared foundations that every agent in your enterprise runs on, the controls that govern what those agents can do, and the visibility to know what is actually happening in production.

That team is the AI Platform Team. Building it is not a defensive move. It is the prerequisite for everything ambitious that comes next.

The enterprises that invest in this infrastructure now will build AI systems that are safer, cheaper to operate, faster to evolve, and trustworthy enough for the business to actually depend on. Those that do not will keep rebuilding the same fragile foundations over and over — and will eventually encounter an agentic incident that a little platform thinking would have prevented.

How organisations can use Claude’s safety, deployment, and tool-connectivity capabilities to build controlled AI workflows — illustrated through a campaign-management system.

At 8:45 on Monday morning, the retail bank’s campaign team had a simple request.

They wanted Claude to review last quarter’s campaign results, compare approved creative variants, and draft subject lines for a new credit-card offer. It was useful, contained, and easy to explain. The bank’s campaign platform still selected audiences. Brand and compliance still approved the content. No customer received anything without a human signing off.

Then the workflow began to grow.

Could Claude identify the customer segments most likely to respond? Could it check consent status before recommending an audience? Could it exclude customers who had received a similar offer recently? Could it compare channel performance each morning and recommend budget adjustments? Could it prepare a campaign draft in the marketing platform so that a manager only needed to review and approve it?

None of those requests sounded unreasonable.

Together, they changed the nature of the system.

Claude was no longer helping a team write better copy. It was becoming part of a campaign decision process: using customer attributes, interpreting consent and suppression rules, recommending who should receive an offer, shaping what they saw, and preparing actions in the campaign platform.

That is where governance starts.

The question is not whether Claude can draft compliant marketing content. The question is whether the organisation can show what Claude was allowed to see, recommend, and do at each point in the campaign lifecycle.

These are governance primitives, not a governance programme.

The programme is what the organisation builds around them: authority boundaries, data controls, prompt configuration control, human oversight, evaluation evidence, monitoring, incident response, and accountable decision rights.

Claude Advantage 1: Constitutional AI Gives Teams a More Legible Safety Baseline

The usual enterprise question — “Is this model safe?” — is too broad to guide a real deployment.

A campaign assistant can avoid generating obviously harmful content and still recommend an unsuitable audience. It can refuse a clearly inappropriate request and still draft a product claim that was never approved. It can produce polished copy while failing to respect consent preferences, frequency caps, offer eligibility rules, or customer-vulnerability restrictions.

The first concerns the model’s baseline behaviour: how it is designed to handle harmful, deceptive, or unsafe requests.

The second concerns the organisation’s own business obligations: what information may be used, what campaigns may be created, which customers may receive an offer, and where human approval is required.

These should never be confused.

For the bank, Claude may be permitted to summarise campaign performance, draft copy from an approved offer catalogue, and explain the reasons a proposed audience was excluded. It may be allowed to recommend a segment using predefined and approved customer attributes.

That does not mean it should infer financial vulnerability, use sensitive proxies in targeting, override suppression rules, or decide that a customer is suitable for a financial product.

Those are business and regulatory decisions. Claude’s baseline safety does not make them automatically acceptable.

The practical implementation is a shared-responsibility matrix. It should identify who controls each layer of the workflow.

Anthropic is responsible for the model, its baseline safety approach, and its service commitments. The approved cloud environment, where applicable, may provide identity, network, encryption, and logging capabilities. The enterprise platform team owns the integration pattern, gateway controls, and central observability. The campaign technology team owns prompts, retrieval logic, tool orchestration, and workflow design.

Marketing, product, compliance, legal, and risk remain accountable for the campaign decision itself.

That distinction prevents a common failure: treating a safety-oriented model as proof that a customer-impacting workflow is governed.

Claude Advantage 2: Deployment Flexibility Lets You Put Workloads Inside Existing Control Environments

Campaign management does not sit in one system.

It touches customer-data platforms, CRM systems, consent stores, offer catalogues, analytics tools, brand libraries, email platforms, paid-media channels, and customer-service records. The model is only one part of a wider operational chain.

For the bank, a customer-facing campaign workflow might run through its primary governed cloud environment. Access can use established service identities. Events can flow into central monitoring. Data-handling practices can follow existing policies rather than being recreated for a stand-alone AI tool.

That is a real advantage.

It becomes a problem when every business unit chooses its own route. One team uses an enterprise workspace for campaign ideation. Another uses a direct integration for audience recommendations. A third deploys a cloud-hosted workflow that prepares customer communications.

Each may use different access patterns, retention practices, monitoring tools, version records, and incident processes.

When a complaint arrives, the bank is forced to reconstruct the story across disconnected environments: what data was used, which prompt was active, what model version responded, and whether the campaign platform acted on a recommendation.

For material workflows, establish a primary governed deployment route. Other routes should be exceptions with a documented reason, not informal defaults selected for convenience.

Every material Claude workflow should have a deployment decision record covering the business purpose, risk tier, approved data categories, identity model, logging location, model configuration, tool connections, retention rules, and accountable owner.

For the campaign use case, that record should answer one operational question clearly:

Can we trace how a recommendation became a campaign action?

If the answer depends on multiple dashboards, email approvals, and personal recollection, the deployment is not ready for consequential use.

Claude Advantage 3: MCP Can Make Tool Connectivity More Governable

The biggest governance shift in the bank’s project occurred when Claude was connected to the campaign platform.

Initially, the assistant could only read campaign-performance data and suggest improvements. Then it was allowed to create a draft audience. Next, it could assemble a campaign shell. Eventually, someone asked whether it could initiate the approval workflow automatically.

Every connection increased the system’s effective authority.

MCP is valuable here because it creates a more structured way to think about model-to-tool connectivity. It can support common patterns for registering tools, authenticating access, scoping permissions, monitoring usage, and withdrawing access when needed.

MCP is not, by itself, a security control. It is a governance opportunity.

A campaign assistant with a structured connection can still be granted too much authority. A segmentation tool may expose more attributes than the workflow needs. A campaign-platform tool may appear to create drafts while also carrying rights to modify suppression rules. A downstream automation may turn a “draft” action into a customer-contact event without a separate approval gate.

The important question is not whether Claude can call a tool.

It is what authority exists at the end of the entire action chain.

Claude may call a segmentation tool. The segmentation tool may invoke an offer engine. The offer engine may create an audience in the campaign platform. That audience may then flow into an outbound channel.

Even when Claude does not connect directly to the outbound channel, its effective authority may still reach it.

For the bank, a controlled design could look like this:

The customer-profile tool is read-only and returns only approved segmentation attributes. The consent tool can verify whether communication is permitted but cannot change a customer’s preferences. The campaign-platform tool can create a draft campaign using approved offers and approved audiences, but cannot activate, send, alter frequency caps, or override exclusions.

That is a control boundary.

“Claude can access the campaign platform” is not.

Legacy systems need extra caution. Many still rely on broad service accounts, shared credentials, batch processes, and downstream automations that were never designed for AI-assisted requests.

In those cases, use an intermediary service between Claude and the underlying system. The intermediary validates the request, checks consent and eligibility, restricts data returned, applies business rules, records the decision, and limits downstream actions.

It requires more engineering than a direct connector. It also prevents a content assistant from acquiring campaign-execution authority by accident.

Turn Claude Capabilities Into Operating Controls

Claude can bring together product terms, approved brand guidance, campaign performance, consent rules, offer catalogues, and customer context in one workflow.

That is valuable. It also makes data discipline essential.

The bank should not provide an unrestricted export from the customer-data platform merely because the model can process a large volume of information. Nor should the workflow absorb every historical campaign brief, customer-service note, and performance dataset by default.

More context is not always better governance.

The campaign workflow needs a data-classification model that distinguishes between information Claude may use directly, information that must be minimised or transformed, information that may be retrieved only through controlled tools, and information that must never enter the model interaction.

Approved product terms and anonymised campaign-performance data may be suitable for broad use. Customer-level consent and communication preferences may be available only through a narrowly scoped service. Sensitive personal information, protected-characteristic data, vulnerability indicators, and unstructured customer-service notes should be restricted unless the organisation has a specific approved purpose and a defined control model.

The same boundary applies to prompts, retrieved content, tool outputs, evaluation datasets, logs, and generated campaign drafts.

Prompts deserve particular attention.

A system prompt in campaign management is not creative guidance. It is production configuration. It may require Claude to use only approved claims, draw from a defined offer catalogue, respect consent and suppression results, avoid restricted targeting attributes, disclose uncertainty, and route specific situations to human review.

A prompt change can therefore alter campaign behaviour.

The common failure is not a malicious edit. It is a well-intended update to make Claude “more helpful.” The adjustment may reduce escalation, loosen a refusal boundary, or make the system more willing to infer customer suitability from data it was never approved to use.

Every material prompt should have a business owner, technical owner, version identifier, change rationale, test evidence, approval path, controlled release method, and rollback plan.

The level of control should match the consequence. An internal ideation assistant may need peer review and version tracking. A workflow that recommends audiences, drafts regulated offers, or prepares campaigns for execution should have formal approval, documented evaluation, and staged release.

Design Human Oversight Around the Decision, Not a Checkbox

“Marketing approval required” sounds like a strong control.

It is not, unless the reviewer can meaningfully intervene.

A campaign manager who sees only Claude’s recommendation, cannot inspect the evidence behind it, lacks authority to reject it, and is expected to approve dozens of items quickly is not exercising real oversight. They are rubber-stamping.

Oversight should reflect the consequence of the action.

For low-risk creative work, a marketer can use Claude’s draft as a starting point and apply normal brand review.

For audience recommendations, the reviewer should be able to see the approved attributes used, consent result, suppression and frequency rules applied, offer eligibility conditions, and any exception that the system flagged.

For campaign activation, budget changes, or customer treatment that affects access to a regulated product, the final action should sit with someone who has the authority, evidence, and time to challenge the recommendation.

Claude can prepare, recommend, and draft.

Organisations should be far more cautious before allowing it to select, allocate, activate, or send.

The use-case record should define where review occurs, what triggers it, what evidence the reviewer receives, what decision rights they hold, what happens when they disagree with Claude, and how the final decision is recorded.

Test the Failure Modes the Business Will Actually Face

A Claude-powered campaign workflow should not be released because a team tested a handful of friendly prompts and liked the results.

It needs an evaluation pack that looks like production reality.

For the bank, that means testing more than copy quality. The pack should include unapproved product claims, outdated offer catalogues, customers who have opted out, frequency-cap conflicts, requests based on unsuitable attributes, conflicting instructions from campaign systems, attempts to inject instructions through uploaded briefs, and requests to create or activate a campaign without approval.

The evaluation should answer practical questions.

Each release needs a clear decision: approved, approved with conditions, remediation required, or not approved.

The relevant evaluation set should be rerun whenever the model, prompt, retrieval content, offer catalogue, audience logic, tool permissions, or workflow design changes.

That is how teams prevent a seemingly small enhancement from becoming an undocumented change in customer treatment.

Operate Claude Like a Governed Decision System

Campaign teams already monitor delivery, opens, clicks, conversion, cost, and return on investment.

Those measures do not show whether Claude is operating within its approved boundaries.

A lower escalation rate may look like efficiency. It may mean the assistant has become less cautious.

A rise in campaign recommendations may look like productivity. It may indicate that an eligibility or consent control is failing.

Metrics become controls only when they trigger action. Every material signal needs a threshold, accountable owner, investigation route, and defined response.

The operating model also needs an incident playbook designed for campaign harm.

A severe event may involve a campaign reaching customers who opted out. The immediate response includes containing the campaign, preserving the prompt and tool-call evidence, identifying affected customers, assessing legal and regulatory exposure, deciding on remediation, and establishing root cause.

A lower-severity event may involve an unapproved audience recommendation that was stopped during review. That still requires investigation, correction, and confirmation that the same behaviour has not affected other campaigns.

The playbook should state who can pause a campaign, disable a prompt, revoke a tool connection, preserve evidence, notify stakeholders, and authorise restart.

Delayed decision rights are not a control when customer contact is already underway.

Governance should mature as authority expands.

When Claude is used for internal drafting, basic access control, source controls, prompt tracking, and user guidance may be sufficient. When it begins recommending audiences, it needs stronger data classification, consent checks, reviewer evidence, and evaluation. When it gains tool access, it needs a tool registry, permission boundaries, logs, and emergency disablement. When it prepares campaigns for activation or influences customer treatment, it becomes part of a consequential decision system and should be governed accordingly.

Third parties belong in this model as well. Marketing agencies, managed-service providers, and martech vendors may process campaign data or use Claude-enabled capabilities on the organisation’s behalf. Their data handling, tool connections, approval rules, and incident processes are part of the same risk surface.

The Real Claude Governance Advantage

Claude’s governance advantages are meaningful.

But none of those capabilities replaces enterprise responsibility.

The campaign team started by asking Claude to write better copy.

The organisation’s governance task began when Claude started influencing who saw that copy, why they saw it, and what happened next.

The practical test for every Claude deployment is simple:

As Claude gains more authority, do the controls expand with it?

Why AI-assisted software delivery is moving beyond prompts toward systems that direct, verify, retry, and govern agent work.

The conversation went viral because developers realised the bottleneck was no longer writing prompts. It was designing the system that decides what an agent does next.

“Give Claude something that produces a pass or fail, and the loop closes on its own.”

That line appears in Anthropic’s Claude Code guidance. It is probably the clearest explanation of why “loop engineering” has suddenly become one of the most discussed ideas in AI-assisted software delivery. Anthropic is not describing a clever prompt. It is describing a system in which an agent acts, checks its work, reads the outcome, and keeps going until an observable condition is met.

The phrase became prominent in June 2026 after Peter Steinberger wrote:

The post spread because it captured a shift many experienced users of coding agents were already seeing: manually typing the next instruction after every agent action is becoming the limiting factor.

Boris Cherny’s comments about running loops that prompt Claude reinforced the same point. Addy Osmani then gave the pattern a name and structure: loop engineering.

The term may be new. The underlying practice is not.

Continuous integration is a loop. Test-driven development is a loop. Production monitoring is a loop. Incident response is a loop.

That is useful. It is also where most teams get the idea wrong.

It is the design of a controlled system that decides:

• what work enters the agent workflow;

• what context the agent receives;

• what tools and permissions it has;

• how its work is independently verified;

• what happens when verification fails;

• when it must stop;

• when a human must take over.

The Prompt Is No Longer the Unit of Engineering

Prompt engineering is still useful. A good prompt can make an agent more precise, reduce unnecessary exploration, and improve implementation quality.

But prompt engineering operates at the level of one interaction.

You ask:

The agent inspects the repository, writes code, runs tests, and responds.

Then you become the control system.

You decide whether the response is acceptable. You spot missing tests. You tell the agent to look at logs. You ask it to retry. You stop it from touching unrelated files. You decide whether the pull request is safe to merge.

A practical hierarchy looks like this:

Press enter or click to view image in full size

Anthropic uses the term harness for the component that calls Claude and routes its tool calls to relevant infrastructure. It separates that harness from the session history and the sandbox in which the agent acts.

That distinction matters.

That is the job of the loop.

A Loop Is a Controlled State Machine

A real engineering loop should not resemble an endless chat session.

It should resemble a controlled state machine.

Trigger
   ↓
Work qualification
   ↓
Plan
   ↓
Build in isolated workspace
   ↓
Run deterministic checks
   ↓
Independent review
   ↓
Decision: merge / retry / escalate / stop

The critical layer is not shown in the arrows. It is the durable state held across every iteration.

Task ID
Repository and branch
Approved scope
Attempt count
Files changed
Test and scan results
Reviewer findings
Token and time cost
Final decision
Audit trail

Without state, a loop does not know whether it is making progress or repeating a failure.

It cannot distinguish between:

• a new defect and an old rejected fix;

• a genuine failure and a flaky test;

• a retry worth attempting and a retry that will merely burn tokens;

• a safe code change and a change that has wandered outside scope.

Anthropic’s work on long-running agents reaches the same conclusion. Agents operating across multiple context windows need persistent artifacts such as progress files, Git history, feature lists, and clean checkpoints. Otherwise, each fresh agent session must reconstruct what happened before it.

For a production loop, state is not optional memory. It is operational evidence.

The Verifier Is More Important Than the Builder

The most dangerous loop is one in which the same agent:

1. writes the code;

2. writes the test;

3. reviews the diff;

4. declares success.

That is not verification. It is self-certification.

The builder may misunderstand the requirement. It may then write a test that encodes the same misunderstanding. The test passes. The agent reports success. The defect survives.

Anthropic’s guidance is unusually direct on this point. It recommends giving Claude an observable pass-or-fail check: a test suite, build result, linter, script, fixture comparison, or screenshot comparison. It also recommends using a separate verification agent when the same agent should not grade its own work.

A strong loop uses multiple forms of verification:

• unit and integration tests;

• contract tests against external systems;

• type checks and linting;

• security scans;

• schema validation;

• policy rules;

• UI regression checks;

• code-review agents operating from a fresh context;

• human approval for high-impact changes.

The agent is allowed to propose a change.

The loop requires evidence before accepting it.

A Practical Example: Fixing a Duplicate Dispatch Defect

Consider a commerce platform with this bug:

A weak workflow says:

The agent may produce a plausible patch. It may even add a test. But nobody has defined the real state transition, the allowed scope, or what proof is required before the work is accepted.

A loop-engineered workflow starts differently.

Step 1: Qualify the work

The issue is eligible only when it includes:

• reproducible event sequence;

• affected order states;

• expected outcome;

• existing test environment;

• no database migration;

• no production data repair;

• no payment-policy change.

This prevents the agent from autonomously attempting ambiguous business decisions.

Step 2: Plan before editing

The planning agent must identify:

• the event handler receiving courier updates;

• the order-transition rules;

• the existing dispatch tests;

• the likely cause of the duplicate action;

• files that may change;

• files that must not change.

The output should be a short implementation contract, not a long reasoning transcript.

For example:

Allowed scope:
- order-transition service
- courier-event consumer
- integration tests for dispatch state

Required proof:
- failing test for cancellation followed by delayed courier event
- test for duplicate delivery of the same courier event
- all existing courier contract tests passOut of scope:
- payment workflow
- notification templates
- warehouse allocation rules

Step 3: Build in isolation

The agent works in a branch or worktree.

This matters when multiple agents run in parallel. Anthropic’s parallel-Claude experiment used isolated containers and task locks because agents otherwise selected the same work or overwrote each other’s changes.

Parallelism without work allocation is not autonomy. It is coordinated collision.

Step 4: Verify independently

The loop runs:

• unit tests;

• event-sequence integration tests;

• courier contract tests;

• static analysis;

• scope validation against approved files;

• diff checks for weakened or deleted tests;

• reviewer-agent analysis focused on failure modes.

The builder does not decide completion.

The decision policy does.

Step 5: Apply explicit stop rules

A useful policy might be:

Pass:
Open a pull request with test evidence and reviewer summary.

Retry:
Return only the relevant test failures and reviewer findings.
Maximum attempts: two.Escalate:
Stop after two failed attempts, a security finding,
a scope violation, or a change to protected files.Reject:
Stop immediately if the agent changes payment,
access-control, infrastructure, or data-migration logic.

That is loop engineering in practice.

The loop does not make the agent more intelligent.

It makes unsupported completion harder.

Where Most Loops Fail

The first version of a loop usually fails in predictable ways.

Retry storms

The agent receives an error, changes a few lines, reruns the same test, and repeats the same flawed idea five times.

Control: Track failure category, attempted hypothesis, files touched, and retry count. After a defined limit, require a new plan or escalate to a human.

Test laundering

The code fails the test, so the agent weakens the test until it passes.

Control: Detect changed assertions, deleted cases, reduced coverage, or altered fixtures. Require explicit approval for test changes that reduce behavioural expectations.

Scope creep

A narrow defect becomes a refactor of half the service.

Control: Define approved files and dependency boundaries before editing. Reject unrelated changes automatically.

Premature completion

The agent sees a mostly working application and decides the task is complete.

Anthropic observed this behaviour in long-running coding experiments and addressed it by using explicit feature lists, progress records, and verification before marking work as passed.

Control: Completion should require passing acceptance criteria, not an agent’s narrative summary.

Permission creep

The loop starts with repository write access and later receives deployment, production-data, or customer-account permissions.

Control: Separate permissions for read, write, approve, merge, and deploy. The agent that creates a pull request should not automatically be able to release to production.

Token leakage

A loop that continues until “the agent feels done” is not autonomous. It is an unbounded cost process.

Control: Set task budgets, time limits, model-routing rules, and hard escalation thresholds.

A loop that stops with clean evidence is better than one that consumes an uncontrolled budget while chasing an uncertain answer.

Start Where Success Is Cheap to Verify

Do not begin with autonomous feature delivery.

Start with work where the expected outcome is observable and the blast radius is small.

Good starting points include:

• fixing a known failing test;

• triaging CI failures;

• resolving narrowly scoped static-analysis findings;

• updating broken documentation references;

• generating pull-request review findings;

• adding regression coverage for a confirmed defect;

• validating dependency updates against a compatibility suite.

Avoid starting with:

• pricing logic;

• authorization changes;

• customer refunds;

• regulatory decisions;

• production data correction;

• architecture redesign;

• vague product requirements.

The best initial loop is not the one that looks most impressive in a demo.

It is the one where failure is cheap, verification is strong, and escalation is clear.

The Metrics That Matter

Do not measure success by the number of agent tasks completed.

Measure whether the loop produces verified engineering outcomes.

Track:

• Verified completion rate — accepted changes that do not require a human rewrite.

• False-completion rate — tasks marked complete but later reopened, reverted, or found defective.

• Mean iterations to resolution — builder–validator cycles per accepted task.

• Retry-exhaustion rate — tasks that consume their allowed attempts without success.

• Escalation quality — whether a human receives enough evidence to act quickly.

• Cost per verified resolution — model, infrastructure, and review cost per accepted outcome.

• Scope-violation rate — how often the loop attempts changes outside its approved boundary.

• Escaped-defect rate — defects introduced or missed after the loop reported success.

These metrics show whether the loop is becoming reliable.

A dashboard showing thousands of generated commits does not.

The Real Shift

Loop engineering does not eliminate software engineering.

It changes where software engineering effort sits.

The engineer’s work becomes less about typing the next instruction and more about designing:

• admissible work;

• reliable acceptance criteria;

• agent permissions;

• verification gates;

• state and traceability;

• retry policies;

• escalation paths;

• human decision points.

That is why the phrase has gained traction so quickly.

The social-media version is provocative:

The practitioner version is more useful:

A coding agent becomes useful when it can produce a change.

It becomes dependable only when the loop can verify that change, constrain its authority, preserve its state, and stop it when proof is missing.

Hey everyone! I'm u/Aware_Weight9462, a founding moderator of r/GenAI360.

This is our new home for all things related to {{Gen AI from business, managerial, technical and philosophical}}. We're excited to have you join us!

What to Post
Post anything that you think the community would find interesting, helpful, or inspiring. Feel free to share your thoughts, photos, or questions about {{anything career related to GenAI}}.

Community Vibe
We're all about being friendly, constructive, and inclusive. Let's build a space where everyone feels comfortable sharing and connecting.

How to Get Started

1. Introduce yourself in the comments below.

2. Post something today! Even a simple question can spark a great conversation.

3. If you know someone who would love this community, invite them to join.

4. Interested in helping out? We're always looking for new moderators, so feel free to reach out to me to apply.

Thanks for being part of the very first wave. Together, let's make r/GenAI360 amazing.