ADR: Enterprise AI Agent Runtime Pattern

Context

Enterprise AI Agent systems are often demonstrated as a single chatbot with many tools. That is risky for workflows involving sensitive data, legacy systems, approvals, or regulated operations. A production-oriented design needs clear state management, trust boundaries, typed handoffs, least-privilege workers, human approval, and observability.

Decision

• Use a workflow-owned runtime where the workflow engine owns state, retry, idempotency, routing, and approval gates.
• Keep agents as specialized workers with minimal tool access.
• Use schema-validated payloads for cross-agent output.
• Treat external files, emails, web pages, and user-provided text as untrusted input.
• Require explicit human approval for write-capable actions unless the workflow is proven low-risk and pre-approved.
• Log every prompt, tool call, source, artifact, eval result, and approval action.

Runtime Layers

1. Ingress: UI, scheduler, event bus, or API gateway.
2. Control plane: workflow engine, policy service, state store, and orchestration.
3. Agent runtime: reader, validator, critic, resolver, and drafting workers.
4. Data and tool plane: document store, connector gateway, artifact store, and tool allowlist.
5. Governance: audit log, eval harness, human review queue, and incident workflow.

Positive Consequences

• Safer than a single all-powerful agent.
• Easier to explain to security, compliance, and business owners.
• Enables regression testing and workflow observability.
• Supports gradual rollout from assistive mode to partial automation.

Trade-offs

• More engineering overhead than a chatbot demo.
• Requires workflow design before tool selection.
• Needs clear ownership between product, engineering, security, and operations.

When to Use

• Sensitive data is involved.
• The workflow has high business impact or multiple systems of record.
• Human approval, audit, or compliance expectations are present.
• The workflow reads external untrusted inputs.