AI Automation Architecture: From Event to Verified Action

The problem: an AI answer is not yet an automation

An AI automation becomes a production system only when a real business event can travel through explicit contracts and end in a verified, attributable action. A model response in a demo is only one intermediate artifact. Production also needs to know what triggered the run, which data version was used, what the system was allowed to do, who approved a consequential decision, whether the target accepted the write, and how the result can be repaired.

This article focuses on that narrow technical question: how should an AI automation be architected from event to verified action? It does not replace the broader AI automation service or AI specialist in Armenia pages. Those pages own commercial discovery intent; this guide provides architecture criteria for evaluating one bounded workflow.

The first design decision is therefore not a model choice. It is a process boundary:

• one named business event;
• one intended outcome;
• one owner of the process;
• a defined set of permitted actions;
• representative normal, ambiguous and failure cases;
• an observable completion condition;
• a recovery path that does not depend on reconstructing the model's hidden reasoning.

If those elements cannot be stated, the workflow is not ready for an autonomous write path. It may still be suitable for discovery, summarization or draft mode. The data-readiness audit helps determine whether the underlying evidence is usable, while the first-pilot value-risk matrix helps decide whether this process slice should be built first.

Requirements before drawing the architecture

Architecture should start with failure consequences and verification, not with the happy-path prompt. A useful requirements brief answers five groups of questions.

1. Event contract

What exactly starts the workflow? An event should have a stable identifier, source, creation time, schema version and correlation identifier. “A new email arrived” is too vague when messages can be duplicated, forwarded, edited or received through multiple channels. A better contract distinguishes the source event from later delivery attempts.

The intake boundary should reject malformed events, preserve the original payload where policy allows it, and record normalization decisions. It should not silently coerce a missing customer identifier into an empty string or invent a currency, language or timezone.

2. Decision contract

What may the AI propose, and what must it never decide alone? A decision contract defines output schema, permitted values, evidence requirements, confidence or abstention behavior, and the conditions that require human review.

The contract is not “return JSON.” It is a business-level boundary. For example, a support workflow may draft a response and classify urgency, but it may not promise a refund, disclose restricted account data or close a complaint without an authorized reviewer.

3. Action contract

What write is allowed in the target system? Each action needs an idempotency key, target resource, precondition, authorization scope and expected acknowledgement. The executor should accept only validated commands, not free-form model text.

The action contract should also define what “success” means. An HTTP 200 can still contain a rejected business operation, a queued state or a partial write. Verification must inspect the target system’s durable state or authoritative receipt.

4. Operational contract

Who owns alerts, approvals, retries and incident decisions? What is the latency budget? How long may an approval wait? Which errors are retriable? When does a run enter a dead-letter queue? Which changes require a rollback?

An architecture without an operator is a diagram, not a service.

5. Evidence and retention contract

Which inputs, source references, model configuration, policy version, decisions, actions and receipts must be retained? Retention should be proportional to business and legal needs. Sensitive raw content should not be copied into every log line merely because observability is required.

TRACE-9: an original event-to-action architecture

TRACE-9 is a reference architecture created for this guide. It separates nine contracts so that each stage can be tested, retried and audited independently.

The initials describe the route, while the nine stages prevent the common mistake of treating inference as execution. The model participates in Evaluate. It does not own Trigger, authorization, final validation, execution, reconciliation or operational diagnosis.

Typed process envelope

The normalized envelope is the handoff between ingestion and decision logic. It should carry business and control state together:

type ProcessEnvelope = {
  eventId: string;
  correlationId: string;
  tenantId: string;
  processType: "support_triage";
  schemaVersion: "1.0";
  occurredAt: string;
  receivedAt: string;
  input: unknown;
  permittedActionTypes: readonly string[];
  policyVersion: string;
  sourceRefs: readonly { id: string; version: string }[];
  attempt: number;
};

This does not need to be the exact implementation language. The important point is that identity, versioning, authorization context and retry state are explicit. A prompt assembled from arbitrary strings cannot serve as the system of record.

Key components and their contracts

Durable intake, not a fragile webhook chain

A webhook handler should authenticate the source, validate the outer schema, assign or verify identifiers, persist the event and acknowledge quickly. Long model calls and target-system writes should not be performed inside the request lifecycle when the source may time out and retry.

A queue is not automatically reliable. The design still needs visibility timeouts, maximum attempts, dead-letter handling and replay rules. Replaying a message must not repeat a completed business action.

Context builder with permission filtering

The context builder retrieves only evidence allowed for this tenant, user, process and purpose. Access control must happen before content reaches the model. Filtering generated text after inference cannot undo an unauthorized disclosure.

Every source should be addressable by stable ID and version. That allows a reviewer to inspect what the system used and allows tests to reproduce a decision without relying on the latest mutable document.

Bounded inference adapter

The model adapter owns provider-specific details: request format, timeout, structured output, model identifier, prompt or policy version, token limits and fallback behavior. Business workflow code should depend on a typed proposal, not on one vendor’s raw response object.

Retries must be bounded. Retrying the same invalid prompt three times is not resilience; it is repeated cost. Schema errors may justify one constrained repair attempt. Rate limits may justify delayed retry. Policy failures should not be retried as if they were transient.

Deterministic validators

Validators check what code can check reliably: schema, required evidence, amount ranges, permissions, version freshness, prohibited actions and cross-field consistency. Model self-critique may support evaluation, but it cannot replace deterministic policy checks.

The validator output should be explicit: accept, human_review, reject or retryable_error. A boolean valid hides why a route was chosen.

Human approval service

Human review needs a durable queue, evidence packet, named authority, decision timestamp, reason and expiry behavior. The reviewer should see the proposed action, material source evidence, uncertainty, policy flags and the effect of approval.

Approval must bind to the exact proposal and relevant resource version. If the account, order or document changes while the item waits, the executor must revalidate rather than apply a stale decision.

Idempotent action executor

The executor accepts a validated command, derives a stable idempotency key and performs the smallest permitted write. It should distinguish transport success from business acceptance.

For systems without native idempotency, maintain an execution ledger keyed by event, action type and target. Use target-side read-before-write carefully: it can reduce duplicates but cannot always close race conditions. Where possible, use conditional writes or version checks.

Reconciliation and observability

After the action, read the authoritative state or verify a durable receipt. Reconciliation answers “did the intended business postcondition become true?” A request log answers only “did we send something?”

Observability should connect the event, proposal, validation, approval, action and receipt with one correlation ID. Useful operational signals include completion rate by route, human-review rate, severe validation failures, duplicate suppression, reconciliation mismatch, latency by stage and cost per successfully verified action.

These are definitions for instrumentation, not performance claims about aicoding.am or any client system.

Failure modes that must be designed, not discovered accidentally

Duplicate delivery

Sources retry. Queues redeliver. Operators replay. Without stable event identity and idempotent execution, one customer message can create two tickets or one approved payment can be sent twice.

Control: immutable event ID, execution ledger, target idempotency key and reconciliation.

Out-of-order events

An update may arrive before a create event, or an older event may be retried after a newer state is active.

Control: source sequence or resource version, conditional writes and explicit stale-event routing.

Stale approval

A reviewer approves a proposal based on yesterday’s balance, inventory or policy.

Control: bind approval to a proposal hash and resource version; re-fetch critical state immediately before action.

Hallucinated or unsupported action

The model proposes a field, discount, recipient or tool call that is not supported by evidence or policy.

Control: allowlisted action schema, source requirements, deterministic validation and abstention route.

Partial write

One target changes but a downstream dependency fails. Blind retry may make the state worse.

Control: explicit saga or compensation design, step-level receipts and an incident route for non-reversible actions.

Retry storm and cost amplification

A provider outage or malformed response triggers multiple retries across webhook, queue, inference and executor layers.

Control: one retry owner per boundary, exponential backoff with jitter, attempt budget, circuit breaker and dead-letter queue.

Permission drift

Access rights or business rules change while cached context remains available.

Control: short-lived authorization decisions, policy version in the envelope and revalidation before consequential writes.

Observability without privacy boundaries

Debug logs accidentally retain full documents, personal data, tokens or secrets.

Control: structured redacted logs, reference IDs instead of raw content, separate protected evidence storage and reviewed retention windows.

Testing the architecture

Production confidence comes from layered tests, not one end-to-end demo.

Contract tests

Validate event schemas, normalized envelopes, model proposal schemas, action commands and target receipts. Include unknown fields, missing fields, version mismatch and malformed dates. Provider adapters should be tested against recorded safe fixtures or a controlled sandbox.

Decision evaluation

Build a versioned set of representative cases: normal, ambiguous, adversarial and prohibited. Score factual support, action correctness, abstention, policy compliance and severe-error count. Evaluate per material segment such as language, channel or process subtype.

Integration tests

Test queue redelivery, target timeouts, expired credentials, rate limits, stale versions and partial acknowledgements. Confirm that retry does not duplicate a completed action.

Failure injection

Deliberately stop the model provider, corrupt one context source, delay approval, return an ambiguous target response and make reconciliation disagree. Verify the route, alert and operator information.

Shadow and draft modes

Run the architecture without consequential writes. Compare proposals with actual outcomes and reviewer decisions. Draft mode is valuable only if corrections are captured in a form that can improve evaluation and rules.

Production checklist

Before enabling a write path, verify:

• one process slice and one accountable owner are named;
• event, proposal and action schemas are versioned;
• source permissions are enforced before inference;
• consequential actions have explicit human boundaries;
• validators return reasoned routes, not opaque booleans;
• retries are bounded and owned by one layer;
• idempotency is tested with duplicate and replay scenarios;
• approvals expire and critical state is revalidated;
• target success is reconciled against authoritative state;
• dead-letter and repair queues have operators and service expectations;
• logs are correlated, structured and redacted;
• model, policy and source versions are traceable;
• severe errors block release;
• rollback or compensation is tested where technically possible;
• cost and latency are measured per verified action, not per model call;
• runbooks identify who may pause, replay, override and restore the workflow.

From prototype to controlled production

A practical rollout has four gates.

1. Replay: run historical or synthetic cases with no external actions. Establish contract validity and decision evaluation.
2. Shadow: process live events but keep outputs invisible to target users. Measure routing, freshness and operational behavior.
3. Draft: show proposals to authorized operators; every consequential action remains manual. Capture corrections and stale-state cases.
4. Bounded action: enable only allowlisted, reversible or tightly contained actions. Expand after stable reconciliation and incident evidence, not after an impressive demo.

Architecture review should end with a decision: the slice is ready for bounded production, needs repair, should remain assistive, or should not be automated yet. The case studies show the kinds of engineering proof that can support that decision. For a specific system, request an architecture review only after the event, owner, intended action and failure consequence are clear.