From Agent Workflow to Production Architecture

An agent workflow is not the final system.

It is the map that makes the final system obvious.

Once you know the triggers, tools, agents, approvals, model routes, evals, and deploy targets, the production architecture stops being a guessing game.

Start with the workflow#

Imagine the workflow:

A Slack engineering triage agent reads a request, gathers GitHub and observability context, drafts a response, runs a policy check, asks for approval when needed, and posts the final answer.

Now the architecture appears.

You need:

• Slack webhook receiver.
• Auth and workspace install flow.
• Agent orchestrator.
• Job queue.
• Tool execution layer.
• GitHub connector.
• Observability connector.
• Context store.
• Model router.
• Audit log.
• Approval UI.
• Notification path.
• Eval runner.

None of that came from vibes. It came from the workflow.

The orchestrator is not enough#

People over-focus on the orchestrator.

The orchestrator matters, but the rest of the system is what makes the agent usable:

• The queue handles slow tools and retries.
• The audit log explains what happened.
• The approval UI makes risky actions safe.
• The model router controls cost and quality.
• The connector vault protects tokens.
• The eval harness prevents silent regressions.

If you skip those, you have a demo with a nice name.

Architecture by workflow section#

Triggers become webhook routes, cron jobs, event listeners, or app actions.

Tools become connectors, MCP servers, auth scopes, rate limits, and audit records.

Agents become prompt modules, model routes, queues, and task runners.

Skills become versioned instruction packs with resources and activation rules.

Guardrails become policy checks, approval gates, and output validators.

Evals become replay suites, red-team cases, and release gates.

Deploy targets become the actual runtime plan.

This is why workflow-first design is faster. You stop debating abstract architecture and start mapping concrete responsibilities.

The build order#

I would build in this order:

1. Workflow spec.
2. Read-only tool layer.
3. Audit log.
4. Orchestrator and queue.
5. Human approval.
6. Writes behind approval.
7. Evals and release gate.
8. Observability and cost tracking.

That sequence keeps risk low. The agent becomes useful before it becomes powerful.

Build it in Codelit#

Try this:

Convert a Slack engineering triage agent workflow into production architecture. Include webhooks, orchestrator, model router, MCP tools, connector auth, queue, audit log, approval UI, eval harness, and deployment plan.

Generate the architecture from an agent workflow

Design the work first. The architecture will tell you what it needs.