Archetype B: Process and Workflow Agents

The most common shape of AI project at an established company

There's an existing workflow that humans run today. Contract review. Ticket triage and routing in IT or HR. Code review at PR time. Inbound lead qualification. Real customers or real colleagues are on the other end of it, and you're proposing that AI do part of it while humans do the rest.

That's Archetype B, and it's the most common archetype in real organizations, more common than the clean research-synthesis problem of the previous lesson. The bar for it is unforgiving: your AI-augmented workflow has to be at least as reliable as the human-only workflow it's replacing, and ideally noticeably better, or it gets reverted within three months.

Why this archetype is uniquely hard

Three reasons Archetype B is harder than it looks, and demos hide all three:

1. The integration surface is the project. You're not building a standalone agent, you're wiring it into a CRM, a ticketing system, an ERP, a communication tool. Half the engineering work is plumbing, not intelligence.
2. The human-in-the-loop point is non-negotiable. Compliance, regulation, customer relationships, brand: there's almost always a human who has to review before something ships. Where you place that human decides whether the system saves time or wastes it.
3. You're competing with "the way we've always done it." The existing manual process carries years of accumulated tribal knowledge. Your AI either matches that knowledge or works around it, often both.

In an Archetype A research pipeline, the deliverable goes to humans who use it downstream. In Archetype B, your system sits inside someone's daily workflow (their CRM, their ticketing tool, their approval flow), and that integration work is most of the engineering. The model itself is closer to five percent of the job than people expect walking in.

The architecture: trigger, orchestrator, two halves, human approval, write-back

The two halves and the human-approval gate are the parts of this architecture that carry the most weight, so it's worth slowing down on both.

The two-halves split

Real workflows have an open-ended part and a rule-bound part, and treating them as one job is the single most common architectural mistake in this archetype.

Why split at all? Different work needs different optimization. Reasoning models are slow but careful; fast models are quick but shallow at planning. Putting the right model on the right job improves quality and lowers cost. In the cost data below, the structured half is consistently a rounding error next to the loop half, precisely because it isn't being asked to reason.

Sessions as processes: the isolation principle

A failure mode that hits Archetype B at scale, and that most teams don't notice because each individual turn looks fine on its own: two unrelated workflows share an agent's context and pollute each other. A compliance review leaves a defensive, hedging tone in the agent's working memory. Three turns later, an unrelated customer-support draft inherits that hedge and reads like a legal disclaimer. Nobody can point to what went wrong, because no single turn was wrong. The architecture leaked.

The countermeasure, credited to Alex Krenel's UC Berkeley talk on OpenClaw's architecture, is OS-grade isolation: treat each work item as its own process.

This is the same principle UNIX settled in the 1970s: two processes don't share memory unless you're explicit about it. OpenClaw applies it to long-running autonomous agents, which is why it doesn't accumulate cross-contamination over weeks of continuous operation.

The audit trail: the manifest is the audit record

In Archetype A, an audit trail makes your deliverable credible. In Archetype B, the audit trail is what makes the system deployable at all. Compliance and legal teams, and often regulators, want to see what the AI did, what the human did, and why each decision was made. Hand them the record and they approve. Don't have one, and they won't.

ticket_id: "rfq_2026-09-12_001247"
external_id: "SF-RFQ-1247"
received_at: "2026-09-12T08:34:00Z"

processing:
  loop_half:
    products_identified: ["EX-001-AB", "EX-002-CD"]
    historical_quotes_referenced: ["Q-2024-088", "Q-2025-103"]
    similar_cases_found: 4

  structured_half:
    pricing_rules_applied: ["volume_discount_tier_2", "loyalty_3yr"]
    completeness_check: PASS
    deviations_from_rules: []

draft_output:
  total_eur: 47200
  delivery_weeks: 8

human_review:
  reviewer: "sales_eng_03"
  decision: "APPROVED_WITH_EDITS"
  edits: ["adjusted delivery to 10 weeks per current capacity"]
  reviewed_at: "2026-09-12T11:20:00Z"

Notice what the manifest captures on both sides of the human gate: not just what the AI produced, but what the reviewer changed. Every edit here is future regression-test material. The next section explains why that matters for evaluation.

"Production-ready" does not mean "deployed"

One of the most expensive misunderstandings in this archetype: production-ready means the system could be deployed, not that it is deployed. What it actually requires:

A twelve-week project delivers a prototype that could be deployed after another three to six months of work by the team that receives it. That handoff is the deliverable, not a live system on day one.

The liveness problem: cron and heartbeat

A failure mode that never shows up in a twelve-week prototype, but kills production agents by month two: the agent can't track time.

The naive options are both broken. Keeping a process running indefinitely is wasteful, brittle, and fails badly on restart. Spawning fresh on each request means the agent forgets long-running commitments and silently drops scheduled work.

The pattern that actually works, also credited to Krenel's OpenClaw architecture analysis, pairs two complementary mechanisms:

Without cron, the agent forgets follow-ups. Without heartbeat, it can't react to anything outside its own request flow. A twelve-week prototype doesn't strictly need either, but the team that receives it will run the system for years, and discovering in month two that it silently drops work is how a working prototype gets rebuilt or killed. Design the hooks in even if you don't activate them.

Evaluating Archetype B

Three metrics that matter here, distinct from Archetype A's accuracy-and-coverage framing because this archetype is judged on the human-AI loop, not just the AI in isolation:

The eval suite is built from real production traces: every rejected case becomes a regression test, and every edited case becomes a test for whether a revised prompt produces what the human had to produce by hand.

Cost reality

Rough math for a 50-case-per-day workflow over a twelve-week build, with 20k input and 2k output tokens for the loop half and 5k input and 1k output for the structured half:

These are Nebius EU Token Factory prices captured at deck-authoring time, not a live or durable price list — re-check current pricing before citing these exact numbers. Three things worth noticing. The spread between premium and lean is six times for the same task: the architecture decision of what goes on which model matters more than which specific model you pick. Even the premium stack is roughly $40 a month at this volume, so a CDTM-scale project's budget is not the real constraint. And the structured-half cost is a rounding error in every stack, because the split into "needs reasoning" versus "follows rules" is what makes the economics favorable in the first place, not which specific model sits on either side of it.

For a twelve-week build, multiply by three to five for experimentation and failed prompts: a realistic total project budget is $30–200 on a lean or balanced stack. At production scale, thousands of cases a day, the lean stack runs around $130 a month, against roughly $2,000 a month for an equivalent premium frontier API with vendor lock-in and data leaving the EU attached.

Failure modes

The wrong-stakeholder failure is the quiet killer among these. Spending twelve weeks building something IT loves, then demoing it to sales and hearing "we'd never use this," isn't recoverable in week twelve. The end-user has to be identified in week one, with weekly feedback from them the whole way through.

Week 1 deliverable

By Friday of week one, on an Archetype B project:

By Friday, the actual workflow is understood, the people who run it today have been consulted, and the compliance conversation has started. Everything after that is building inside known constraints.