From Patterns to Agents: Translating System Patterns into Agentic AI

Why old system patterns still matter when designing agentic AI

Agent = Goal, Plan, Tools, Memory/State, Autonomy Envelope, Feedback.
Patterns predict failure. Label the workflow; name the risk (delivery semantics, idempotency, ordering, compensation, state).
Wrap with M–G–E–O. Mode adherence ≥95%; guardrails in tools; step-level evaluation; full observability trail.

We don’t need to rename old problems to make agents work. The failure geometry is familiar: coordination, state, side-effects. Classic patterns (microservices, event streams, state machines, sagas) still apply. The work is translating them into agency without confusing more routing for more intelligence.

What counts as a real agent (not a glorified flow)

“Agent” gets mislabeled. A webhook relay, a chained prompt, or a branching flow isn’t agency — it’s orchestration in disguise. A real agent is defined by the components it carries, not the tools it calls.

At minimum: Goal → Plan → Tools → Memory/State → Autonomy Envelope → Feedback.

If any one is missing, you don’t have an agentic system, it’s a scripted runner. And that distinction matters. What makes agentic AI valuable isn’t just getting from input to output, but deciding how within a bounded scope of autonomy, and recovering when the path fails.

Pattern fluency → agentic translation

Once you know what makes a real agent, the next question is how to reason about the systems they live in. Architects have spent decades codifying solutions to coordination problems (microservices, orchestration, state machines, sagas). These aren’t just old abstractions; they’re diagnostic tools.

When you can look at a workflow and say, “This is event-driven with out-of-order risk,” or “This is a state machine with a missing transition,” you move from describing behavior to predicting failure.

Microservices → Agents calling services in parallel

Where teams stumble: agents reason, then hit external APIs. Each dependency multiplies fragility.
Classic: decompose into independently deployable services.
Agentic: a planner fans out to tools/APIs concurrently.
Risk: fan-out latency, partial failures, inconsistent reads.
Default invariants: P95 tool call ≤ 800 ms; retries with jitter; idempotent endpoints; enforce read-your-writes when actions chain.
👉 Takeaway: Microservices give agents modular reach; every added dependency is a new failure point.

Event-Driven → Agents reacting to signals

Where teams stumble: false positives and noisy signals masquerade as “real-time intelligence.”
Classic: pub/sub with at-least-once delivery.
Agentic: agents act when signals fire (flags, user actions, model scores).
Risk: at-least-once delivery, out-of-order events, duplicates → cascades.
Default invariants: sequence numbers + dedup keys; signal thresholds; quarantine lane for noisy topics.
👉 Takeaway: Event-driven makes agents responsive; without filtering, you automate noise.

State Machines → Agent memory as explicit states

Where teams stumble: when state isn’t explicit, agents infer context without evidence.
Classic: enumerated states with legal transitions.
Agentic: belief/state formalized (e.g., active → restricted → closed) with guards.
Risk: missing transitions, illegal re-entry, state divergence across components.
Default invariants: forbidden-transition tests; state convergence checks; snapshot + audit log.
👉 Takeaway: State machines provide guardrails; rigidity becomes brittleness when reality doesn’t fit the diagram.

Orchestration → Agent as conductor

Where teams stumble: sequencing gets mistaken for agency.
Classic: central controller sequences tasks.
Agentic: a coordinator agent plans, dispatches, evaluates steps.
Risk: controller SPOF, unbounded plan growth, queue starvation.
Default invariants: circuit breaker on planner; max plan depth = 5; per-tool concurrency caps.
👉 Takeaway: Orchestration gives order; if the conductor stalls, the system stalls.

Choreography → Agents acting independently

Where teams stumble: autonomy without shared rules looks like chaos.
Classic: services react without a central brain.
Agentic: peer agents coordinate via shared events/context.
Risk: duplicate work, conflicting actions, races.
Default invariants: ownership tokens/leases; conflict-resolution policy; single writer of record.
👉 Takeaway: Choreography feels free; without coordination, agents step on each other.

Saga Pattern → Agent workflows with rollback logic

Where teams stumble: most agent workflows assume forward-only success.
Classic: distributed transactions via compensations.
Agentic: planned steps include undo paths for side-effects.
Risk: missing compensation, non-idempotent side-effects, long partial-commit windows.
Default invariants: compensation coverage map; idempotent writes; saga timeout ≤ 60 s with escrow/holds.
👉 Takeaway: Sagas let agents undo mistakes; missing compensations turn errors into permanent damage.

Circuit Breaker → Agents cutting off bad tools

Where teams stumble: one flaky tool can melt the system if not isolated.
Classic: open/half-open/closed around a dependency.
Agentic: disable a tool/strategy after error thresholds.
Risk: thrash (rapid open/close), global outage via shared breaker.
Default invariants: per-tenant breakers; exponential backoff; quorum health check before half-open.
👉 Takeaway: Agents need circuit breakers; otherwise one faulty tool drowns the system.

Observer → Agents subscribing to each other

Where teams stumble: “awareness” without throttling creates update storms.
Classic: subjects notify observers on change.
Agentic: agents subscribe to peer outputs or shared memory.
Risk: update floods, missed signals, stale beliefs.
Default invariants: change filters; coalescing window ≈ 500 ms; belief TTL ≈ 15 min; periodic resync.
👉 Takeaway: Observer keeps agents in sync; without filters, updates become overload.

Scoped autonomy and the fallback ladder

The hard shift from flows to agents is bounding autonomy without blunting it. If an agent can do anything, it’s a liability. If it can do nothing without permission, you’ve rebranded orchestration.

Autonomy Envelope = what an agent may do without a human.

• Allowed actions

• Spend limits (e.g., cap per session)

• Blast radius (e.g., restricted to one account)

• Data scopes

• Escalation contract

Fallback Ladder = recovery sequence when things go wrong.

• Verify inputs and assumptions

• Retry with jitter/backoff

• Degrade to a cheaper/safer plan

• Compensate to undo side-effects

• Escalate to a human or system of record

Named failure patterns:

• Runaway autonomy: acting outside the envelope due to weak constraints.

• Silent collapse: error occurs but the agent fails without context.

• Escalation loop: ping-pong between agent and human/tool of record without resolution.

This is the bright line: orchestration sequences; agency chooses within an envelope and justifies its choices. Real agents balance autonomy and safety in real time.

The hidden failure patterns to design against

Most agent failures come from repeatable modes that teams haven’t named. Give them language and a fix, and they’ll design against them.

• Spiral logic → planner loops (“try tool A again”) without new evidence until timeout.
  Antidote: enforce max plan depth and require new evidence to re-attempt a tool.

• Tool flapping → rapid enable/disable from noisy health checks causes instability.
  Antidote: add hysteresis to health checks and a cool-down before re-enable.

• Split-brain state → agent belief diverges from the system of record.
  Antidote: anchor to a single source of truth with periodic state reconciliation.

• Orchestrator choke → controller backlog starves time-sensitive plans while hoarding stale ones.
  Antidote: priority queues and deadline-aware scheduling.

• Context rot → outdated memory drives confident but wrong actions.
  Antidote: TTL on beliefs and evidence refresh before high-impact actions.

The safeguards stack (wrap this around any pattern)

Think of safeguards as a 4-box frame you overlay on any agent pattern. If one box is missing, resilience is already compromised.

M–G–E–O = Mode, Guardrails, Evaluation, Observability.
💡 If it’s not in M–G–E–O, it isn’t reliable — it’s lucky.

Mode adherence
Keep the agent inside its declared mode (explore, execute, escalate). Target ≥95%; anything lower is drift.

Guardrails
Autonomy envelopes, circuit breakers, spend caps must live in tools, not prompts. A safeguard that depends on model compliance isn’t a safeguard.

Evaluation
Measure success per step, not just per workflow. Plan-quality scores, run-time metrics, compensation audits. Without evaluation, you’re flying blind.

Observability
Log the decision trail: goal, plan, tools chosen, state before/after, evidence, confidence, compensation. If you can’t replay it, you can’t operate it.

Where Reliability Really Breaks

I assumed better planning would fix unreliable behavior. It didn’t. Plans fail where guarantees are missing — idempotency, ordering, compensation, explicit state. Once I treated those guarantees as first-class, reliability stopped being a personality trait of the model and became an architectural property of the system.

Closing: build agents engineers can trust

Before you ship, answer three questions:

1. Which pattern am I actually using?

2. What risk did that introduce?

3. Which safeguard neutralizes it—in code and in ops?
   Example: Pattern: event-driven. Risk: duplicates. Safeguard: dedup key + idempotent consumer + quarantine lane.

Do that and you’re not just moving tokens around. You’re designing autonomy that holds under pressure.

👋 Hey, I’m Sarah. I’m gathering perspectives on how these frameworks land in real-world systems — reply or DM me if you’re exploring this.

→sarahpayne.ai for frameworks, visuals, and what’s coming next.