Architecture study · Agentic AI

Useful AI agents need boundaries as much as intelligence.

A reference architecture for tool-using agents that can complete multi-step work while keeping permissions, cost, failure recovery, and human accountability explicit.

Study typeReference architecture
DomainEnterprise agentic AI
Core stackJava 21 · Spring AI · PostgreSQL
Primary focusGovernance & reliability

01Problem frame

A chat response is ephemeral; an agent changes state. Once a model can query customer data, create tickets, trigger workflows, or spend money, prompt quality is no longer the only engineering concern.

The platform must separate probabilistic reasoning from deterministic authority. Models can propose a plan, but identity, permissions, validation, approval, and side effects remain controlled by conventional software.

02Control plane

Every run begins with an authenticated principal, a declared goal, allowed data domains, permitted tools, a time limit, and token and cost budgets. These constraints are stored with the run and cannot be broadened by model output.

A policy gate evaluates each proposed action against role, resource, environment, risk tier, and current approval state. Denials become structured observations the agent can handle safely.

03Execution path

The orchestrator maintains durable run state and invokes models through a gateway that centralises routing, timeouts, quotas, and redaction. Tools are discovered from a registry, but each invocation still passes through policy enforcement.

04Tool contracts

Tools expose narrow, versioned schemas with explicit read or write semantics. Arguments are validated independently of the model, and tool responses return structured facts rather than prompt-ready prose wherever possible.

Write tools require an idempotency key and publish a receipt containing the target, policy decision, before-and-after reference, and correlation ID. High-impact actions pause for human approval with a concise preview of the proposed change.

05Memory & knowledge

Short-term working state belongs to the run; durable user memory requires a separate consent and retention policy. Retrieval is filtered by tenant, identity, document permissions, and data classification before context reaches a model.

Retrieved text is treated as untrusted data, not instruction. Provenance travels with each fragment so answers and actions can cite the evidence used and investigators can reconstruct the decision path.

06Reliability & safety

Durable checkpoints allow a run to resume after model, tool, or network failure. Step limits, loop detection, circuit breakers, and budget exhaustion prevent runaway execution. A cancellation signal propagates to queued and active work.

Input and output controls address data leakage and prompt injection, but the strongest protection is architectural: tools never inherit model authority, secrets are not placed in prompts, and consequential actions are independently authorised.

07Evaluation & operations

Pre-release evaluation covers task completion, policy compliance, tool selection, argument accuracy, groundedness, latency, and cost. A versioned scenario set includes adversarial instructions, unavailable tools, stale data, and partial failures.

Production traces connect the user request, model calls, retrieved sources, tool executions, approvals, and final result without storing raw sensitive content by default.

Boundedexplicit tools, steps, and budgets
Durablecheckpointed, resumable execution
Auditableevidence for every side effect

08Takeaway

An enterprise agent should be treated as an untrusted planner inside a trusted execution system. Bounded authority and observable state make the platform safer—and make agent behaviour far easier to improve.

← Back to all case studies