Cookbook
Decide what belongs to an agent and what belongs to an automation
Indraft has no workflow builder and is not going to grow one. That is only a defensible position if you have a clear answer for what to do instead, so here it is, including the half that should not be an agent.
The situation
You are moving off a CRM that had a workflow builder: if-this-then-that rules, assignment logic, alerting, drip sequences. Some of it you relied on. You want to know what replaces it before you commit.
The honest answer is two things replace it, and using the wrong one is the most common mistake people make in their first month.
The test
Does the work require reading something and deciding, or does it require doing the same thing every time?
If a rule can express it, write the rule and put it somewhere deterministic. If a rule cannot express it, that is what an agent is for. The failure mode in both directions is real and worth naming.
An agent doing an automation's job is slow, costs money per run, and is non-deterministic in a place where you wanted determinism. A Slack notice that arrives ninety percent of the time is worse than no Slack notice, because you will come to rely on it.
An automation doing an agent's job is the thing you are leaving behind. It is the lead-scoring rule that was right in 2023, the assignment logic with fourteen exceptions, the sequence that emails a customer who churned last week. Rules cannot read context, so people encode more and more of it into conditions until nobody can say what the system will do.
How the work actually divides
| The job | Which | Why |
|---|---|---|
| Logging a call from your notes | Agent | It has to read prose and decide what mattered. No rule expresses that. |
| Posting to Slack when a deal is won | Automation | Same input, same output, every time. An agent here is a slower, more expensive, less reliable webhook. |
| Deciding which inbound leads are worth a call | Agent | Judgement against context that changes weekly. |
| Creating a contact from a form submission | Automation | The form already told you the fields. There is nothing to work out. |
| Chasing a quiet deal | Agent | Whether to chase, and what to say, depends on the last conversation. |
| Nightly export to the warehouse | Automation | It must be identical every night and it must not be clever. |
| Summarising a thread into an interaction | Agent | Reading and compressing is the entire job. |
| Alerting when a deal over 50k moves backwards | Automation | A threshold and a comparison. Write it once and stop thinking about it. |
Read down the middle column. Everything an agent owns involves reading prose or weighing something that changed since last week. Everything an automation owns is a shape you could describe to a colleague in one sentence and they would implement it the same way you would.
What the automation side has to work with
Three things, and between them they cover what a workflow builder did.
Webhooks, for when something happens. Subscribe to the operations you care about and Indraft posts to your endpoint. The event names are a published list rather than free text, so subscribing to something that does not exist is refused at the moment you subscribe instead of silently never firing.
Agent
That refusal is the point. The failure it prevents is subscribing to
company.updated, seeing no error, and finding out three weeks
later that no such event was ever going to arrive.
The change feed, for catching up. Everything that happened, in order, with a watermark. This is what you poll if you are keeping a warehouse or a spreadsheet in step, and it is what you use to recover after your endpoint was down: webhooks retry, but the feed is the thing that cannot miss.
The API, for doing. Every operation an agent can perform is an ordinary HTTP call, so your workflow creates the contact, opens the deal, or files the task itself.
Where the two meet
The interesting workflows use both, and the seam is usually the same shape: an automation notices, an agent decides.
You
When a deal over fifty thousand goes quiet for two weeks, post it to the pipeline channel with the last three interactions and what I said I would do.
The noticing is a rule: an amount, a date comparison, a schedule. The "what I said I would do" is reading. So the schedule and the threshold live in your automation, and it hands the account to the agent to write the message. Neither half is doing the other's job, and you can debug them separately when the notice looks wrong.
The thing that is genuinely gone
Sequences. There is no drip campaign engine, no enrolment, no step-based cadence with wait conditions, and nothing here replaces one. If your motion depends on automated multi-touch outbound, that lives in a tool built for it, and Indraft is where the results land.
That is a real gap rather than a philosophical position, and it is worth knowing before you switch rather than after.
Verify your split
- For each automation, ask what happens when it is wrong. If the answer is "somebody notices immediately", it is a good automation. If the answer is "the data is quietly wrong for a month", the rule is carrying judgement it should not.
- For each agent job, ask whether you could write the rule. If you can write it in one sentence with no exceptions, write it. You will get a faster, cheaper, more predictable version of the same thing.
- Check your webhook deliveries. They record attempts, the response status, and the retry time, so an endpoint that has been quietly failing is visible rather than assumed.
Run it again
Revisit the split whenever you add something. The common drift is toward the agent: it is easier to ask than to write a rule, and six months later a dozen deterministic jobs are being done by something that charges per run and occasionally has an opinion.