Design the Agent Workflow Before You Write Agent Code#

Most agent projects start in the wrong place.

Someone opens a framework, connects Slack, adds a GitHub tool, writes a heroic system prompt, and calls it an agent.

That can work for a demo. It falls apart the second the agent touches real work.

The hard part is not getting a model to call a function. The hard part is deciding what kind of work the agent is allowed to own, when it should stop, which systems it can touch, which model should handle each step, and what evidence proves it did the right thing.

That is an agent workflow.

The workflow is the product#

If you are building a support agent, the workflow is not "answer support questions."

It is:

• Receive a question from Slack, Intercom, email, or the app.
• Classify whether it is billing, product, bug, account, or escalation.
• Pull context from docs, tickets, logs, and customer state.
• Draft an answer with source links.
• Require approval before refunds, account changes, or external commitments.
• Record what happened.
• Measure whether the answer was useful.

That shape matters more than the first prompt.

The prompt will change. The model will change. The workflow is what lets the team reason about the system.

Start with five boring questions#

Before tools, ask this:

1. Who can trigger the agent?
2. What outcome is the agent responsible for?
3. What can it read?
4. What can it write?
5. What requires a human click?

If you cannot answer those questions, you are not ready to wire production apps.

This is especially true for small teams. A startup can move fast, but it cannot afford an agent that posts the wrong thing to a customer, changes billing by accident, or makes a deploy call nobody can trace.

The right object is not a chatbot#

A chatbot is a conversation.

An agent workflow is an operating plan.

It includes:

• Triggers
• Agents
• Skills
• Tools
• MCP servers
• Model routes
• Guardrails
• Evals
• Harnesses
• Deploy targets

That sounds like more work until you realize it prevents rework. Instead of discovering missing approvals after a scary demo, you put them in the design from day one.

A practical example#

Say you want a Slack engineering triage agent.

Do not start with:

Build me a Slack bot that answers engineering questions.

Start with:

Build a Slack engineering triage workflow that classifies internal requests, gathers evidence from GitHub, Linear, Notion, and observability tools, drafts a response, and requires approval before posting incident conclusions or opening production-impacting tickets.

That prompt already contains the product:

• Slack is the trigger.
• GitHub, Linear, Notion, and observability are tools.
• Evidence gathering is a separate step from response writing.
• Incident conclusions are high risk.
• Approval exists before the agent speaks with confidence.

Now the architecture becomes obvious. You need a Slack webhook, an orchestrator, connector auth, a queue, audit logs, human approval UI, model routing, and eval harnesses.

The trap#

The trap is thinking the agent becomes safer once the model gets better.

It does not.

A better model can still take the wrong action if the workflow gives it vague permissions. A better model can still cite private data if the tool layer hands it private data. A better model can still sound confident when it should ask for approval.

Safety lives in the workflow, not just the model.

Build it in Codelit#

Use Codelit's Agent Workflow mode when you want to design the work before you wire the work.

Try this:

Design a Slack engineering triage agent for a small startup. It should classify requests, gather repo and incident context, draft responses, require approval for risky actions, and generate the production architecture.

Build this agent workflow in Codelit

The point is simple: do not start with agent code. Start with the workflow the team can trust.