How We Build AI Agents for Real Business Workflows

A single prompt can summarize a document or draft an email. It cannot run a workflow: research a company across dozens of sources, qualify it against your ICP, draft a personalized message and log the result — because a workflow has state, steps, tools and quality gates.

When teams try to force a workflow into one prompt, the result is unreliable: context exceeds the window, the model loses track of the stage, errors are not caught, and nobody can explain why the output is wrong. That is the gap agents were built for.

An agent is not a chatbot that acts; it is a worker with a role, tools and a task list — plus someone who checks its work.

• Map the workflow — write down every step, every input, every decision point and who does the work today.
• Decompose into roles — each step becomes a specialized agent: researcher, analyst, writer, reviewer.
• Define tools and access — which APIs, databases and services each agent can use, with least-privilege access.
• Orchestrate with checks — an orchestrator routes work between agents, and quality gates validate output at each stage.
• Add the human loop — critical steps require human review and approval before any external action.

The workflow map is the real deliverable. If a process cannot be described step by step, no agent system will fix it — the process needs fixing first.

The architecture we use for multi-agent systems is deliberately simple:

• Orchestrator — decides which agent handles what, tracks the workflow stage and enforces timeouts and retries.
• Specialist agents — each with a narrow role, a strict output format and its own tool set.
• Shared state — the workflow state lives in PostgreSQL: what was done, what data each step produced, who approved what.
• Tool layer — agents call real tools (CRM, Telegram, email, internal APIs) through typed interfaces with permissions.
• Logging and metrics — every step is logged with model, tokens, latency and outcome, so quality is measurable per agent.

Single-agent systems are still the right choice for narrow tasks. We add the second agent only when the workflow has two genuinely different types of work.

To make the architecture concrete, here is one complete agent cycle from a sales workflow — how a single target company moves through the system (illustrative, no client data):

{
  "agent": "reviewer",
  "message_id": "msg_4821",
  "status": "approved",
  "checks": [
    { "check": "persona_match", "passed": true },
    { "check": "policy_compliance", "passed": true },
    { "check": "factual_claims", "passed": true }
  ],
  "score": 0.92,
  "comment": "Approved with minor tone edit in the opening line"
}

Every step is logged with model, tokens and latency. When a step fails validation, the cycle returns to the responsible agent instead of moving forward — that loop is what makes multi-agent systems reliable instead of just impressive.

• Model per role — classification and extraction run on cheap fast models; research synthesis and strategy run on frontier models.
• Model routing — OpenRouter lets us switch providers per role and cap costs without changing application code.
• Structured output — agents return typed JSON with schema validation, not free text, so the orchestrator can trust and route results.
• Guardrails — output validators, retry policies and refusal handling keep the agent inside its boundaries.
• RAG for knowledge — when an agent needs company context, we attach a retrieval layer instead of stuffing documents into the prompt.

Our products are the best documentation of this approach:

• LeadForge AI — a multi-agent sales system: a research agent scans 50+ sources per company, ICP and persona agents build targeting profiles, and a content agent drafts personalized outreach. A reviewer agent checks every generated message before it reaches the pipeline.
• AI Business Copilot — a multi-agent diagnostics system: agents analyze processes, data and tooling to find automation opportunities, with a RAG knowledge base as shared context.

Both products run the same pattern in production: narrow roles, typed outputs, logged steps and a human review loop on everything that leaves the system.