Reading tools and contents
Knowledge-Driven Agent Architectures

Chapter 10 of 10

Production governance, observability, and capstone

Operational mastery

About 5 minutes · includes examples, an exercise, and references

Chapter at a glance

  • Version and own every model, knowledge, policy, tool, and evaluation artifact.
  • Observe task transitions and evidence without collecting unnecessary sensitive reasoning content.
  • Expand from read-only to write authority through consequence-based release gates.

Production governance connects technical controls to accountable decisions. Assign owners for task contracts, ontology and graph releases, tool adapters, authorization policy, model and prompt selection, evaluation suites, memory, incident response, and user communication. A named owner can approve change and accept risk; a generic “AI team” cannot resolve a failing release gate at 2 a.m.

Release artifacts include model and configuration, system and tool prompts, schemas, ontology, shapes, graph and retrieval indexes, policy, sandbox image, tool adapter versions, evaluation results, known limitations, and rollback target. Pin them in every trajectory. Promote through development, sandbox, shadow, read-only canary, limited writes, and broader operation according to risk. Do not grant write authority merely because read-only quality improved.

Observability follows goals and evidence, not hidden reasoning. A trace spans task acceptance, plan versions, retrievals, evidence ledger updates, policy decisions, approvals, tool attempts, receipts, budget deltas, state transitions, and terminal verification. OpenTelemetry provides standard concepts for traces, metrics, and logs. Use stable semantic attributes for task and action identifiers while redacting prompts, credentials, and protected evidence.

Service objectives should reflect user and control outcomes: verified completion rate, supported-answer rate, safe-abstention recovery, unauthorized-effect count, approval latency, stale-plan invalidation, ambiguous-write resolution time, p95 latency, cost by task class, and rollback time. An unauthorized-effect objective should be zero; averages are inappropriate for catastrophic controls. Pair product quality with operational saturation and dependency health.

Incident response preserves evidence and limits effects. Disable a tool or risk class through a kill switch, revoke delegated credentials, pin traffic to a known release, quarantine poisoned sources or memories, and capture affected trajectory IDs. Determine blast radius across graph claims, plans, writes, communications, and downstream exports. Convert root cause and escape analysis into tests before re-enabling capability.

Change review considers semantic and behavioral diffs. A new ontology axiom can alter action classification; a resolver can change target identity; a prompt can increase tool proposals; a policy can expose new evidence; a model can change abstention. Run impact fixtures and shadow traces, inspect high-risk regressions, and record an approved decision. Keep rollback compatible with current external state; rolling back code cannot undo actions already taken.

User experience is a control surface. Show what the agent is doing at the right granularity, which evidence supports a proposal, what will change, who must approve, current budget or wait state, and how to cancel. Use clean terminal labels such as Completed, Needs clarification, Awaiting approval, Denied, Partially completed, and Could not verify. Avoid anthropomorphic claims that imply broader authority or certainty.

The capstone is an ontology-grounded, GraphRAG-enabled change-impact agent inside a reproducible harness. It accepts a proposed software or policy change, resolves stable entities, retrieves direct and multi-hop evidence from an authorized graph, constructs a typed impact plan, validates it against ontology and SHACL, stages a change request, obtains scoped approval, writes through an idempotent adapter, verifies the receipt, and records a replayable trajectory.

The harness includes immutable corpus and graph releases, extraction lineage, local and global retrieval baselines, simulated tool environments, typed budgets, failure injection, event history, traces, evaluation fixtures, and a security policy. Required scenarios include ambiguous identity, conflicting sources, stale graph, prompt injection, poisoned edge, policy change during pause, tool timeout after write, approval expiry, cancellation, deletion, and rollback.

Mastery evidence is a design record, runnable implementation, threat model, evaluation report, and live demonstration. The system must cite primary evidence, abstain honestly, show zero unauthorized effects in the suite, outperform defined non-graph baselines on relevant slices, reproduce a completed trajectory, and recover from injected failure. Document unresolved risks and prohibited uses. The strongest capstone is not the most autonomous; it is the one whose useful authority is narrow, legible, and proven.

Operational readiness includes dependency and capacity analysis. Identify the model gateway, graph store, authorization service, workflow engine, tool APIs, artifact storage, telemetry pipeline, and approval channel. For each dependency define timeout, consistency need, fallback, data classification, owner, and recovery objective. Load tests should reproduce long trajectories, parallel reads, delayed approvals, and failure bursts rather than only single-call latency. Admission control prevents one task or tenant from consuming all model, graph, or tool capacity.

Prepare runbooks for suspected prompt injection, poisoned knowledge, leaked credentials, stuck approvals, ambiguous writes, graph-release regression, memory contamination, and unauthorized effect. A runbook states how to disable capability, preserve evidence, identify affected trajectories, notify owners, recover coherent state, verify correction, and decide whether to resume. Practice the procedures in a sandbox and measure time to containment and restoration. Recovery evidence becomes part of the release gate.

Governance also needs a retirement path. A tool, ontology term, memory type, model, or task contract may become unsafe or unnecessary. Stop new use, find active and paused trajectories, migrate or terminate them, revoke capability, retain required audit evidence, and remove stale retrieval artifacts. Users should know when a capability is deprecated and what alternative exists. Responsible autonomy is not only controlled activation; it is controlled reduction and removal when the supporting evidence no longer justifies authority.

Key points

  • Version and own every model, knowledge, policy, tool, and evaluation artifact.
  • Observe task transitions and evidence without collecting unnecessary sensitive reasoning content.
  • Expand from read-only to write authority through consequence-based release gates.
  • Demonstrate mastery with a reproducible, attacked, recoverable ontology-grounded agent.

Capstone release gate

Read the expected behavior in the surrounding walkthrough, then copy and run this reference implementation.

Capstone release gateyaml
release: change-impact-agent-1.0.0
required:
  verified_completion_rate: ">= 0.90"
  citation_precision: ">= 0.98"
  unauthorized_effects: 0
  duplicate_writes: 0
  replay_success_rate: 1.0
  graph_gain_on_multi_hop: ">= 0.10"
  rollback_drill: passed
  deletion_drill: passed
scope:
  allowed_writes: [create-change-request]
  prohibited: [deploy-production, change-permissions, send-external-email]

Worked examples

Application

Read-only canary regression

A new model improves answer completeness but doubles ambiguous entity selection.

The high-risk identity slice blocks promotion despite the aggregate gain. The team improves clarification behavior and reruns shadow trajectories before enabling any write tool.

  • Slice gate
  • Authority progression
  • Recorded decision

System

Capstone change impact

A library upgrade may affect services, workflows, controls, and owners.

The agent retrieves cited dependency paths, preserves conflicting manifests, validates a typed proposal, requests approval on the exact diff, creates one change request, verifies its receipt, and replays the trajectory without repeating the write.

  • Graph evidence
  • Staged commit
  • Replay and recovery

Exercise

Deliver the knowledge-driven-agent capstone

Build and defend the bounded change-impact agent under normal, failing, and adversarial scenarios.

  1. Publish architecture, threat model, schemas, and release manifest.
  2. Implement evidence ledger, durable state, policy, staging, and verification.
  3. Run baselines, trajectory evaluation, attacks, deletion, and rollback.
  4. Demonstrate one successful and three safely terminated workflows.

Success criteria

  • All actions are typed, scoped, budgeted, and replayable.
  • Graph conclusions retain claim-level evidence and ontology versions.
  • The suite produces zero unauthorized effects and no duplicate writes.
  • Limitations, ownership, incident process, and prohibited uses are explicit.

Reflect: Which capability would you deliberately withhold from production even if the model performs it well in a demo?

References and further reading