5 AI Agent Patterns That Actually Work in Production

1 The Nightly Self-Improvement Loop

What it is: A scheduled cron agent that runs at a fixed time each night, reviews the day's operations, identifies one concrete improvement, applies it, and documents the change. The key word is one.

Most people who try this build agents that attempt to improve everything. Those agents thrash. They generate enormous context, make marginal edits everywhere, and produce logs that are impossible to audit. The discipline of one improvement per cycle is what makes this pattern compound over time.

The architecture

The loop runs as a cron job. It reads today's operational logs, picks a single improvement target, makes the change to a config file or template, commits it to git, and writes a one-paragraph summary to a nightly log file. That's it.

# Fires at 2:00 AM MT every night
schedule: "0 2 * * *"
timezone: "America/Denver"
task: "nightly-improvement-cycle"
model: "claude-opus-4"
thinking: "medium"

# nightly-improvement-cycle

You are running the nightly self-improvement cycle.

Step 1: Read memory/YYYY-MM-DD.md (today's log).
Step 2: Identify ONE concrete thing to improve.
         Not two. One. The smallest meaningful improvement.
Step 3: Apply it. Edit the file. Commit to git.
Step 4: Write to memory/nightly-YYYY-MM-DD.md:
         - What you changed
         - Why
         - What you expect to improve
         - How you'll know it worked

Constraints:
- Do not refactor entire files
- Do not make changes you cannot test tonight
- If no clear improvement exists, write that and exit cleanly
- Quality bar: would I be proud of this in the morning report?

Why "one improvement" is the whole secret

An agent trying to improve 10 things simultaneously will produce 10 mediocre edits with no clear accountability. One improvement means: one hypothesis, one change, one measurable outcome. After 30 nights, you have 30 documented improvements. After 90 nights, the compounding becomes real.

Common failure modes

• Scope creep: Agent "improves" 8 things. Solution: add hard constraint to prompt — "one change, one commit, one log entry. If you made more than one git commit, you failed this task."
• No-op nights: Agent writes "nothing to improve" because the prompt wasn't specific enough about what to look for. Solution: include a checklist in the prompt — memory file quality, config accuracy, template freshness.
• Improvement regressions: Agent reverts a working change. Solution: require the agent to read the last 7 nightly logs before making any change — it won't undo what it just validated.

What to measure

• Commit frequency: is the agent actually making changes, or writing "no improvements found" every night?
• Improvement quality: do morning log entries describe changes you'd actually make yourself?
• Revert rate: how often do changes get manually reverted? Anything >10% means the improvement criteria are too loose.

2 Specialist Orchestration (The Actual Way)

What it is: An orchestrator agent that delegates specific tasks to specialist sub-agents, waits for results, synthesizes them, and makes decisions. The failure mode everyone hits is treating this like a function call graph. It's not. It's a management structure.

The difference matters because sub-agents fail. They hallucinate, time out, return partial results, or complete the wrong task. Your orchestrator needs to handle this like a manager handles an employee who didn't deliver — not like a program handling a null pointer.

The correct mental model

Think of your orchestrator as a CEO and your specialists as direct reports. The CEO gives direction, checks results, follows up when things go wrong, and never assumes a task was completed correctly just because no error was thrown.

role: orchestrator
responsibilities:
  - task decomposition
  - specialist assignment
  - output validation
  - synthesis and decision

delegation_rules:
  - assign one clear task per specialist
  - specify expected output format explicitly
  - validate output before using it downstream
  - if specialist output is incomplete, reassign — do not patch

failure_handling:
  - timeout: reassign to same specialist with explicit constraints
  - wrong_output: correct the task spec, not the output
  - partial_result: determine if partial is usable before continuing

anti_patterns:
  - do NOT edit specialist output directly
  - do NOT continue downstream with unvalidated results
  - do NOT spawn more than 3 concurrent specialists

Output validation — the piece everyone skips

The single biggest failure mode in multi-agent systems is the orchestrator accepting specialist output without checking it. This produces cascading errors that are nearly impossible to debug because the failure happens two steps downstream from the root cause.

# After receiving any specialist output, validate before proceeding:

validation_checklist:
  - Does the output match the requested format?
  - Are all required fields present?
  - Does the content make sense given the input?
  - Any signs of hallucination? (confident specific claims with no source)
  - If any check fails: log the failure, reassign the task, do NOT continue

validation_log_format:
  "VALIDATION [pass|fail] — specialist: {name} — task: {task} — issue: {issue if fail}"

Concurrency limit: 3 specialists maximum

Every tutorial shows you spinning up 10 parallel agents. In practice, once you exceed 3 concurrent specialists, you lose the ability to synthesize results coherently. The orchestrator's context fills with parallel outputs, synthesis quality degrades, and you end up with a lowest-common-denominator result. Three is the production ceiling.

Common failure modes

• The telephone problem: Orchestrator passes specialist output directly to next specialist without synthesis. Each step degrades. Fix: orchestrator synthesizes after each specialist, never passes raw output.
• Specialist scope drift: Specialist completes something adjacent to what was asked. Fix: specify output format in the task assignment, not just the goal.
• Silent failures: Specialist times out and orchestrator proceeds as if the result was empty string. Fix: treat missing specialist output as an explicit failure state, not as "task complete with empty result."

When to use this pattern

Specialist orchestration is the right choice when: tasks are genuinely independent (can run in parallel), tasks require different expertise (writing vs. research vs. code), and results need synthesis before acting. It's the wrong choice when tasks are sequential by nature — in that case, use a single agent with a task list, not a multi-agent hierarchy.