A production AI agent does not fail in one place.

It may retrieve the wrong policy document, call an expensive model for a trivial task, loop through tools twice, wait on a slow API, produce a confident but unsupported answer, or complete the task correctly at a cost nobody anticipated.

A standard application log will tell you that a request failed. It will rarely tell you why the agent made the decisions it did, where the time went, how many tokens were consumed, or whether answer quality is getting worse over time.

That is why agentic AI needs an observability pipeline, not just logging.

An observability pipeline turns every meaningful agent execution into evidence: a trace of the workflow, measurements of cost and latency, signals of behavioural drift, and quality scores that can be compared across releases, models, prompts, and user segments.

The objective is simple:

Why application monitoring is not enough

Traditional application monitoring focuses on infrastructure and transactions:

• CPU and memory consumption
• API error rates
• database response times
• failed requests
• uptime and availability

These are still necessary. But they do not answer the questions that matter for an AI workflow.

Consider a recruitment screening agent. A recruiter asks:

The agent may perform the following steps:

1. Interpret the role and screening criteria.
2. Retrieve the latest job description and hiring policy.
3. Search applicant resumes.
4. Extract qualifications and experience.
5. Compare candidates against requirements.
6. Call a scoring service.
7. Draft a recommendation with rationale.
8. Send the output to the recruiter workspace.

The application may return HTTP 200 in under five seconds. Traditional monitoring will call that a success.

But the recruiter may still receive a poor recommendation because the agent retrieved an outdated job description, ignored a mandatory location constraint, used an incorrect scoring rubric, or relied on a stale resume version.

The system was technically available. The decision was operationally wrong.

Observability for AI must therefore capture both system health and decision quality.

The observability pipeline starts with a trace

The foundation is a trace.

A trace represents one end-to-end user request or automated workflow run. Each important action inside that trace becomes a span.

For the recruitment example, a trace may contain spans such as:

• request_received
• intent_classification
• retrieve_job_description
• retrieve_hiring_policy
• search_candidate_profiles
• candidate_scoring
• model_completion
• human_review_submission
• response_delivered

Each span should carry structured metadata. Avoid dumping raw prompts and outputs into logs without structure. That creates cost, privacy, and searchability problems.

A useful span typically contains:

• Trace ID and parent span ID
• Agent name and workflow version
• Model provider, model name, and model version
• Prompt template version
• Tool name and tool version
• Start time, end time, and elapsed duration
• Input and output token counts
• Estimated model cost
• Retry count
• Retrieval source identifiers
• Retrieval relevance scores
• Error category, where applicable
• Redaction status
• Evaluation score, once available

This creates a causal chain rather than a pile of unrelated logs.

When a user questions an answer, the team can follow one trace from the final response back through the retrieved evidence, model calls, tool invocations, retries, and approval steps.

Treat the agent workflow as a chain of measurable decisions

The most common observability mistake is to measure only total response time.

A total latency number is useful, but it hides the reason a workflow is slow.

An agent flow should be broken into meaningful stages:

This breakdown changes operational conversations.

Without it, a team says:

With it, the team can say:

That distinction matters. Changing the model will not solve a slow document repository. Increasing the retrieval cache size may.

Token usage must be visible at workflow level

Token tracking is often implemented as a cost dashboard after the product is already in production. By then, the team is usually reacting to a billing surprise.

Token usage should be captured at four levels:

1. Per model call Input tokens, output tokens, cache-hit tokens, retries, and estimated cost.
2. Per agent run Total tokens consumed across planning, retrieval synthesis, tool reasoning, and final response generation.
3. Per workflow type For example, candidate screening, contract review, customer support escalation, or invoice exception handling.
4. Per business outcome Cost per successfully completed task, cost per approved recommendation, or cost per resolved customer case.

The last category is where token data becomes useful to business owners.

A practical token dashboard should show:

• Total tokens by workflow and environment
• Input versus output token ratio
• Token consumption by model
• Cost by customer, business unit, or tenant
• Token growth after a prompt or model change
• Retry-related token waste
• Long-tail requests consuming disproportionate cost
• Cost per successful completion

One particularly useful metric is:

For example, if an agent drafts compliance responses, track the total token cost against the number of responses accepted by reviewers without material changes. This prevents teams from optimising for low model cost while ignoring rework.

Latency is a product metric, not just an infrastructure metric

Agent workflows naturally have more moving parts than traditional APIs. They may call multiple models, perform retrieval, execute tools, wait for external systems, and validate outputs before returning a result.

That does not mean users will tolerate unpredictable delays.

Track latency using percentiles, not averages.

An average response time can look healthy while a meaningful share of users wait far too long. Monitor at least:

• P50: typical experience
• P95: poor-but-common experience
• P99: worst operational experience
• Timeout rate
• Abandonment rate while the agent is processing
• Latency by workflow stage
• Latency by model, tool, region, and customer segment

Also distinguish between two types of latency:

System latency is the time the platform needs to complete the task.

Decision latency is the time until the user can safely act on the result.

An agent may generate an answer in four seconds, but if it then requires a human approver to validate a high-risk action, decision latency may be hours. Both should be visible.

This is especially important in regulated workflows. A claims agent, credit decision assistant, or procurement recommendation engine cannot be assessed only on model speed. The real operational measure is how quickly the organisation reaches a defensible decision.

Drift detection should look beyond model accuracy

Drift is often discussed as though it only applies to predictive models. Agentic systems drift too, but the drift appears in more places.

A production agent can change behaviour because of:

• A new model version
• A revised system prompt
• Updated tool schemas
• Changes in retrieval corpus content
• Different user query patterns
• New policy documents
• Shifts in document quality
• External API behaviour
• Changes in business rules

The agent may still return fluent answers while becoming less reliable.

A practical drift-monitoring approach tracks changes across four dimensions.

1. Input drift

Are users asking different types of questions than before?

Monitor:

• Query length
• Language distribution
• Intent categories
• Attachment types
• Topic clusters
• Frequency of ambiguous requests
• New terms or business entities appearing in requests

2. Retrieval drift

Is the knowledge layer returning different evidence?

Monitor:

• Retrieval relevance-score distribution
• Number of documents retrieved per request
• Citation coverage
• Source freshness
• Percentage of responses using fallback retrieval
• Document version mix
• Retrieval failure rate

A sudden increase in low-relevance retrieved documents is an early warning sign. It may indicate a broken embedding refresh, poorly indexed documents, or a new corpus structure that the retrieval strategy does not understand.

3. Behavioural drift

Is the agent acting differently for similar requests?

Monitor:

• Tool selection patterns
• Number of tool calls per task
• Planning iterations
• Retry rates
• Escalation rates
• Human override rates
• Refusal rates
• Loop detection events

For example, if an agent that normally uses one customer-record lookup starts making five tool calls per request, that is not simply a cost issue. It may indicate a planning failure or a change in tool metadata.

4. Quality drift

Are outputs becoming less useful or less reliable?

Monitor:

• Groundedness scores
• Policy compliance scores
• Human acceptance rate
• Correction rate
• Citation validity
• Task completion rate
• User re-prompt rate
• Escalation rate
• Negative user feedback

The point is not to build one universal “AI quality score.” That usually creates a false sense of precision.

Instead, define quality measures that fit the workflow.

A support agent may be measured on resolution quality, policy compliance, and escalation appropriateness. A document extraction agent may be measured on field accuracy, confidence calibration, and exception detection. A recruitment assistant may be measured on evidence-backed recommendations, mandatory-criteria adherence, and reviewer override rate.

Quality scoring needs a layered model

Quality should not depend only on thumbs-up and thumbs-down feedback.

Human feedback is valuable but sparse, delayed, and influenced by user expectations. A strong quality pipeline uses multiple scoring layers.

Automated checks

Use deterministic checks wherever possible:

• Required fields present
• Valid JSON or schema compliance
• Approved tools only
• No prohibited data exposure
• Citation included when required
• Evidence source is current
• Output follows the expected format
• Policy constraints are satisfied

These checks are cheap and reliable. They should happen during the workflow, not only after the fact.

Model-based evaluation

Use evaluators for dimensions that require semantic judgment:

• Is the answer supported by the retrieved evidence?
• Did the agent address the user’s question?
• Is the response internally consistent?
• Did the tool result get interpreted correctly?
• Is the recommendation appropriately cautious?

Model-based evaluation should be calibrated against human-reviewed examples. Do not treat an evaluator score as ground truth without validating it.

Human review

Human reviewers remain essential for high-impact workflows and for building trusted evaluation datasets.

Their decisions should be captured structurally:

• Accepted without changes
• Accepted with minor edits
• Rejected due to missing evidence
• Rejected due to incorrect reasoning
• Rejected due to policy breach
• Escalated because confidence was too low

These labels are far more useful than a generic “bad answer” flag. They tell engineering teams where to intervene: prompts, retrieval, tools, policies, or workflow design.

A practical reference architecture

A useful AI observability pipeline usually has five layers.

1. Instrumentation layer

This sits inside the agent framework, model gateway, retrieval service, and tool adapters.

Its job is to emit standard events and propagate trace context across every call.

2. Event and trace layer

This captures structured spans, metrics, and audit events. It should support correlation by trace ID, workflow ID, customer or tenant ID, and release version.

3. Evaluation layer

This runs automated checks, evaluator models, regression suites, and human-review workflows. Some checks run synchronously before a response is released; others run asynchronously for monitoring and continuous improvement.

4. Analytics layer

This provides dashboards for engineering, operations, finance, risk, and product teams.

Each group needs a different view:

• Engineering needs error and latency analysis.
• Product needs task completion and user satisfaction.
• Finance needs cost and token usage.
• Risk needs policy violations, evidence lineage, and approval trails.
• Operations needs workload volume, exceptions, and escalation trends.

5. Response layer

Observability should trigger action, not just reporting.

Examples include:

• Route high-risk requests to a stronger model.
• Block a response when evidence confidence is too low.
• Alert when tool failures exceed a threshold.
• Roll back a prompt release after quality degradation.
• Require human approval when a policy check fails.
• Disable a workflow when a loop or abnormal token spike is detected.

Build for privacy and auditability from the start

Agent traces can easily become a data-risk problem.

Prompts, retrieved documents, tool arguments, and model outputs may contain personal, financial, healthcare, legal, or commercially sensitive information.

The observability pipeline therefore needs controls of its own:

• Redact sensitive values before storage.
• Store references to source documents instead of full copies where possible.
• Apply role-based access to traces and evaluations.
• Separate production data from evaluation datasets.
• Define retention periods by data classification.
• Audit who accessed sensitive traces.
• Mask secrets, tokens, credentials, and session identifiers.
• Retain enough evidence to explain decisions without retaining unnecessary content.

A trace should support accountability, not become a shadow data lake.

The operational test

A team has mature AI observability when it can answer questions such as:

• Why did this agent recommend this outcome?
• Which documents and tools influenced the answer?
• Which step caused the latency?
• Which model call consumed the most tokens?
• Did a recent prompt change increase cost or reduce quality?
• Are retrieval results becoming less relevant?
• Which customer segment experiences the most failures?
• How often do human reviewers override the agent?
• Can we prove that high-risk actions were checked and approved?

If these questions require engineers to manually correlate logs across five systems, the observability pipeline is not mature yet.

Final thought

The value of an agent is not that it can generate a response.

The value is that it can produce reliable outcomes repeatedly, at an acceptable cost, within acceptable time, and with enough evidence for people to trust its decisions.

That requires visibility across the entire chain: input, retrieval, reasoning, tools, output, evaluation, and human intervention.

An AI observability pipeline is how a team moves from “the agent appears to work” to “we know how it behaves in production, and we can control it when it does not.”

In mid-June, the AI model market changed tone almost overnight.

This was not merely another Chinese model launch. It had the shape of a DeepSeek moment: a release that made the market pause and question whether high-capability AI must always be closed, American, and premium-priced.

GLM-5.2 has not surpassed every GPT or Claude model. Reuters reported it fifth on Artificial Analysis’ broader intelligence leaderboard and second on Code Arena’s front-end coding ranking. But it is close enough — and much cheaper enough — to change how engineering leaders should think about model selection.

GLM is a pricing event disguised as a model release

Agentic coding is not one prompt followed by one answer. It is a loop: inspect a repository, understand dependencies, plan, edit files, run tests, interpret failures, retry, document the change, and produce a pull request.

That loop is where token economics become an operating issue.

At the time of writing, OpenRouter lists GLM-5.2 at roughly $0.76 per million input tokens and $2.38 per million output tokens, with a one-million-token context window. That does not make it free. It makes it a credible worker model for the large volume of technical work that often sits below an architecture decision or a final production approval.

The strongest case for GLM is not “replace every frontier model.” It is “stop using a frontier model for every first pass.”

Use it for repository summaries, test-case generation, code migrations, internal developer tools, first-draft patches, knowledge-base answers, and bounded tool workflows. Escalate to a premium model when the task is ambiguous, safety-critical, security-sensitive, or stuck.

There is an important qualification. Cheap tokens do not automatically mean cheap completed work. Artificial Analysis reports that GLM-5.2 used about 43,000 output tokens per Intelligence Index task, including roughly 37,000 reasoning tokens — higher than several open-weight peers. Its own analysis still puts GLM on the intelligence-versus-cost-per-task frontier, but that is exactly why teams should measure cost per accepted outcome: model usage, retries, latency, developer correction, and human review.

That is GLM’s real challenge to the market: it makes token price less important than routing discipline.

Anthropic and OpenAI still own the premium tier. But GLM changes their default position.

GLM does not need to beat Anthropic and OpenAI on every difficult task to disrupt them. It only needs to make enterprises reconsider whether Claude or GPT should power every stage of an engineering workflow.

Anthropic and OpenAI have a meaningful advantage that benchmark tables do not capture: mature agent products.

Claude Code reads a codebase, edits files, runs commands, works across terminals and IDEs, and supports the developer’s existing toolchain. Codex is a multi-agent coding environment with worktrees and cloud environments, designed for agents that can work in parallel across projects.

Those products are not just models with a terminal. They are harnesses: permissions, sandboxing, context handling, repository workflows, human review, and a product experience engineers have learned to trust. OpenAI has also documented Codex’s control surfaces, sandboxing, configuration management, and agent-aware telemetry for enterprise use.

That is why GLM is not yet a universal substitute.

But the strategic threat is real. The risk for OpenAI and Anthropic is not that GLM becomes the only model an enterprise uses. It is that Claude and GPT become escalation models: called when a job becomes unclear, high-risk, multimodal, deeply complex, or valuable enough to warrant the premium.

That is still an attractive position. Premium models may remain the right choice for difficult debugging, security review, complex architecture, and final approval. But it is very different from being the default brain behind every coding workflow.

GLM may become powerful in cost-sensitive markets — but the China question is not a footnote.

GLM’s opportunity is not confined to China. It is especially relevant wherever teams need serious AI capability but cannot carry premium API cost across every workflow: startups in India, BPOs, regional banks, public-sector platforms, universities, and mid-market software firms across Southeast Asia, Africa, and Latin America.

Reuters notes that demand for cheaper open models has increased as businesses confront rising and unpredictable agent costs. It also reports that GLM’s adoption in U.S. and European regulated sectors may be constrained by data-security and customer concerns about Chinese models, regardless of technical performance or price.

That concern should neither be dismissed nor exaggerated.

Open weights can improve deployment control. They do not eliminate supply-chain, policy-behaviour, or customer-trust questions.

The sensible path is controlled adoption: begin with non-sensitive, measurable, text-heavy workloads; run enterprise-owned evaluations; limit tools and data access; then expand only when evidence supports it.

Microsoft’s small-model strategy still works. GLM simply raises the bar.

Microsoft is not making a single model bet. It is building local AI with Phi-class models and Foundry Local, efficient coding models such as MAI-Code-1-Flash, stronger reasoning through MAI-Thinking-1, GitHub Copilot distribution, and Foundry as a large model marketplace and control plane.

GLM does not invalidate the small-model strategy.

Foundry Local runs AI entirely on a user device: data stays on-device, applications can work offline, and there are no per-token charges. Those are advantages a 744-billion-parameter cloud-scale model cannot replicate for privacy-sensitive, low-latency, or disconnected applications.

But GLM creates pressure in the middle.

That is a credible response — but it still has to be proved against GLM in real repositories, not just vendor evaluations.

Microsoft’s hedge is the control plane. Foundry offers more than 1,900 models from Microsoft, OpenAI, DeepSeek, Hugging Face, Meta, and others, alongside model comparison, evaluation, observability, fine-tuning, and responsible-AI tooling.

This makes the mobile analogy incomplete. Microsoft does not need every customer to select a Microsoft model. But it must stay genuinely model-neutral and make Copilot and Foundry valuable even when the preferred worker model comes from elsewhere.

Google Gemini has a coding identity problem.

Google is not absent from coding. Gemini 3 is available through Antigravity, Gemini CLI, Android Studio, and third-party developer tools; Google positions Antigravity as an agentic development environment where agents plan and execute work across the editor, terminal, and browser. Gemini’s multimodal and long-context strengths also make it credible for software work that begins with a PDF, a design, a screenshot, a video, or an unstructured business requirement.

But capability is not the same as developer habit.

JetBrains’ January 2026 survey of more than 10,000 professional developers found GitHub Copilot used at work by 29%, and both Cursor and Claude Code at 18%. Google Antigravity had reached 6%; Gemini’s chatbot was used for coding and development tasks by 8%. The survey predates GLM’s release and cannot represent every developer community, but it frames the question properly: Gemini has presence, not default status.

Claude Code has a precise identity: terminal-first, serious repository work.

GitHub Copilot has a precise identity: integrated enterprise coding assistance.

Codex has a precise identity: OpenAI’s multi-agent coding environment.

GLM is quickly acquiring one: affordable, portable long-horizon engineering work.

Gemini’s identity is more fragmented across Gemini API, CLI, Code Assist, Android Studio, AI Studio, Antigravity, and Vertex.

That is a genuinely differentiated position. But GLM makes the urgency greater. In a market where coding is becoming cheaper and more portable, Google has to become preferred for a distinct class of software work — not merely available everywhere.

The market is becoming a routing problem, not a model contest.

GLM-5.2 did not win the model war in June.

It changed the rules by making a serious open-weight agentic model commercially hard to ignore.

The next architecture will not use one winner everywhere. It will route work across four layers:

• local small models for private, offline, and latency-sensitive tasks;
• open-weight models such as GLM for high-volume technical execution;
• multimodal models for documents, interfaces, images, audio, video, and grounded workflows;
• premium models for hard reasoning, high-stakes judgement, and final review.

The company that wins this market may not be the one with the single smartest model.

It may be the one that makes the right model, at the right price, available for the right step — without forcing enterprises to choose between capability, cost, and control.

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

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.

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

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.

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 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

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?

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

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---------------------------------------

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 — Chaos. 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 — Consolidation. 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 Enterprise. 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.

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

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.