A multi-step AI agent is an LLM-driven system that completes a goal through a controlled sequence: interpret the request, create or follow a plan, call approved tools, retain relevant state, validate results, and escalate uncertain cases to a person. Unlike a one-prompt chatbot, it can gather data, compare evidence, update software, and pause before consequential actions.
For a non-US founder, the best agent architecture is usually not a fully autonomous bot. It is a bounded LLM workflow with deterministic business rules around the model. Give the LLM tasks involving language and ambiguity; use code for calculations, permissions, validation, and system updates.
The practical design is: plan → tools → memory → guardrails → human handoff. Reliability then comes from retries, idempotency, evaluations, logs, and clear approval thresholds.
The Core Architecture of a Multi-Step AI Agent
A production agent needs more than a model and a long prompt. Separate its components so each can be tested, replaced, and monitored independently.
| Layer | Responsibility | Typical implementation |
|---|---|---|
| Trigger | Starts the workflow | Webhook, email, schedule, CRM event |
| Planner | Breaks the goal into bounded steps | LLM with a structured JSON schema |
| Tools | Reads data or performs actions | HubSpot, Stripe, Gmail, QuickBooks, APIs |
| Memory | Stores workflow state and approved context | PostgreSQL, Redis, vector database |
| Guardrails | Enforces formats, permissions, and limits | Schema validation, allowlists, business rules |
| Handoff | Routes exceptions to a person | Slack, email, ticket queue, admin dashboard |
Plan explicitly, but limit freedom
Ask the model to return a typed plan such as research_company, verify_domain, and draft_summary. Reject unknown actions. For predictable processes, use a fixed state machine and let the LLM make narrow decisions inside each stage.
Set hard boundaries: a maximum of 8 steps, 2 retries per tool call, and a 5-minute workflow timeout are reasonable starting points. Tune them with observed data rather than allowing open-ended loops.
Expose narrow tools
Prefer create_invoice_draft over unrestricted database access. Every tool should define required inputs, output schema, timeout, permission scope, and whether repeating the call is safe. Separate read tools from write tools, and require approval before sending money, contacting a lead, or posting accounting entries.
Memory, Guardrails, and Human Handoff
Use three kinds of memory
- Working memory: the current run's inputs, tool outputs, and decisions.
- Business memory: durable records such as customer IDs, vendor rules, and prior approvals.
- Retrieval context: relevant excerpts from policies, product documentation, or playbooks.
Store facts in systems of record rather than relying on conversation history. Keep provenance: the source, retrieval time, and field used. Never place API keys, full bank credentials, or unnecessary personal data in prompts.
Turn policies into executable guardrails
A prompt saying “be careful” is not a control. Validate currencies, totals, dates, email domains, and required fields with code. Apply role-based permissions and tool allowlists. Treat webpages, PDFs, and emails as untrusted input because they may contain instructions intended to redirect the agent.
The model may recommend an action; deterministic code decides whether that action is permitted.
Define handoff rules before launch. Examples include confidence below an internally tested threshold, conflicting evidence, a duplicate invoice candidate, or any payment-related action. The reviewer should receive the source material, proposed action, reasons, and an approve/edit/reject control.
Case Study 1: Sales Research Agent for Inbound Leads
Suppose a visitor submits a demo form. The goal is to enrich the lead and prepare a useful briefing without fabricating facts or automatically sending an inappropriate message.
End-to-end LLM workflow
- Trigger: HubSpot or Salesforce sends a webhook containing the lead's name, work email, company, and consented form data.
- Normalize: code validates the email, extracts the domain, and filters free-email domains for separate handling.
- Research: approved search or enrichment tools retrieve the company website, public description, location, and relevant product pages.
- Verify: the agent compares the domain and company identity across sources. Conflicts trigger review.
- Classify: the LLM maps evidence to a defined segment and produces citations for each material claim.
- Write: it generates a 100–150 word CRM summary and a draft outreach message.
- Act: the system updates approved CRM fields. A salesperson reviews the message before sending.
Useful tools may include HubSpot, Salesforce, Clearbit, Apollo, a search API, and Slack. Availability, coverage, and pricing differ by country and plan, so design fallbacks rather than assuming every lead can be enriched.
Failure controls and evaluation
Cache research by company domain for 7–30 days to reduce repeated calls, while recording retrieval dates. Retry transient API errors with exponential backoff and jitter. If the CRM update times out, use an idempotency key based on the lead ID and workflow version so a retry does not create duplicate notes.
Before launch, build a labeled set of at least 50 representative leads, including free-email addresses, sparse websites, subsidiaries, and conflicting company names. Score field accuracy, citation support, correct escalation, tool failure recovery, and accidental overwriting of verified CRM data. Review samples weekly after launch.
Case Study 2: Invoice-Processing Agent
An invoice agent can reduce manual data entry, but financial records require stricter controls than sales research. Its safe role is to extract, validate, match, and prepare a draft—not autonomously approve or pay an invoice.
End-to-end processing sequence
- Ingest: receive a PDF or image from a dedicated inbox or upload form; scan the file and retain its checksum.
- Extract: OCR and document models capture vendor name, invoice number, currency, dates, line items, tax, and total.
- Validate: code checks that line-item math reconciles with subtotal, tax, and total within the currency's expected precision.
- Match: look up the vendor and purchase order in QuickBooks, Xero, NetSuite, or your internal database.
- Detect duplicates: compare vendor, invoice number, amount, date, and file checksum with existing records.
- Code: the LLM proposes an account category based on documented rules and prior approved examples.
- Review: route mismatches, missing purchase orders, bank-detail changes, and low-confidence fields to finance.
- Post: after approval, create a draft bill and attach the original document plus an audit trail.
Controls that matter
Do not let emailed text override workflow rules. Bank-detail changes should always receive independent verification outside the email thread. Keep payment execution in a separate permission boundary from extraction and bookkeeping.
Test with at least 100 documents spanning currencies, credit notes, multi-page invoices, poor scans, handwritten additions, and duplicate files. Measure exact-field accuracy, arithmetic validation, duplicate detection, false approvals, and reviewer correction time. A system that extracts quickly but misses duplicate invoices is not reliable.
Reliability Patterns for Production
Retries without duplicate actions
Retry only failures likely to be temporary, such as rate limits or network timeouts. Use exponential backoff, cap attempts, and send exhausted runs to a dead-letter queue. Write operations need idempotency keys and a pre-action status check.
Evals before and after release
Create a versioned evaluation set from realistic, redacted examples. Run it whenever you change the prompt, model, tools, schemas, or business rules. Track task completion, unsupported claims, escalation quality, latency, cost per completed run, and tool errors—not only whether the response sounds good.
Production checklist
- Define the permitted outcome and explicit prohibited actions.
- Use structured outputs and validate every field.
- Set tool timeouts, retry limits, and an overall step budget.
- Make all write operations idempotent and auditable.
- Log prompt version, model, tool inputs, outputs, and decisions securely.
- Redact unnecessary personal and financial information.
- Create approval queues with response-time ownership.
- Maintain a kill switch and a manual fallback process.
- Run regression evals before each production change.
Choosing the Right Level of Autonomy
Use a simple decision framework. If a task is reversible, low-value, easy to verify, and based on trusted data, the agent can act automatically. If it is difficult to reverse, affects money or customers, uses ambiguous evidence, or has regulatory implications, require human approval.
Start with “draft and review” for 2–4 weeks. Examine corrections and exceptions, automate only stable paths, and preserve review for rare or high-impact cases. This progressive approach is usually faster than debugging an over-autonomous system after it damages CRM or accounting data.
Frequently Asked Questions
Is a multi-step AI agent different from Zapier automation?
Zapier typically follows predefined triggers and actions. An agent adds language understanding and bounded decision-making. They can work together: Zapier orchestrates events while the LLM classifies or drafts.
Should I use one agent or several specialized agents?
Start with one orchestrated workflow and narrow tools. Add specialized agents only when responsibilities, permissions, and evaluation criteria are clearly separable.
Do I need a vector database?
Not always. Use ordinary database queries for structured facts. Add vector retrieval when the agent must search substantial unstructured material such as policies or product documentation.
How much human review is enough?
Review all high-impact actions initially. Reduce review only after evaluations and production samples show that a specific path is stable, reversible, and correctly escalated.
When Founder Portal Can Help
Founder Portal can help non-US founders connect company setup, Stripe or banking operations, and practical AI automation—especially when the workflow must fit the systems used by a new US company.