Workflow Platform or Write the Agent Yourself?

The question is how much the path branches

Almost every argument here resolves once you describe the work honestly.

If you can draw the flow in advance, with the branches known and the steps fixed, that is a workflow. When a form is submitted, enrich the record, check a condition, write to two systems, and notify someone. Nothing about that requires a model deciding what to do next, and expressing it as an agent adds nondeterminism to a process that had none.

If the path depends on what is found, that is an agent. Read this ticket, work out what kind of problem it describes, gather whatever context that requires, and either resolve it or escalate with a summary. You cannot draw that in advance because the steps depend on the content.

The expensive mistake runs in both directions. Agents used for deterministic work produce variable results on a task that had a correct answer, and they cost more per run. Workflows used for open-ended work become sprawling branch trees that encode a decision nobody can maintain, and every new case adds another branch.

What each side is actually good at

Platforms win on connectors. Authenticated integrations with dozens of services, token refresh handled, webhooks received, retries built in. Reproducing that in code is weeks of unglamorous work per integration, and it is the single most underrated reason platforms are worth their cost.

Platforms win on visibility. A visual flow can be read by an operations lead who will never open your repository. Run history shows what happened on a specific execution without adding logging. For handover, audit, and shared ownership with non-engineers, that is a real advantage rather than a cosmetic one.

Code wins on version control and review. Diffs, branches, pull requests, and the ability to see what changed and when. Platform version histories are usually weaker, and a workflow edited directly in production by whoever was on shift is a genuine operational risk.

Code wins on testing. You can unit test a function. Testing a visual workflow generally means running it, which is slow and often has side effects.

Code wins on complexity. Once you need real state, concurrency control, or intricate error handling, workflow tools become an awkward way to express a program you should have written as a program.

A hybrid that holds up

The arrangement that works for most teams is to keep the platform for what it is good at and to isolate the judgment.

The workflow handles the trigger, the integrations, the retries, and the record of what ran. When it reaches a step that genuinely requires reading and deciding, it calls out to a service that runs the agent, and that service returns a structured result the workflow acts on.

This gives you three properties worth having. The nondeterministic part is small, contained, and independently testable, because the agent is a function with an input and a typed output rather than something woven through the flow. The deterministic part stays visible and maintainable by people who are not engineers. And the boundary between them is a good place to put validation, so a strange model output fails the step rather than propagating into three systems.

Set a per-run cost ceiling at that boundary as well. A workflow that fires on every inbound message and calls a model each time is the standard way a cheap automation becomes an expensive one, and platform run limits do not know about token spend.

The part both approaches get wrong

Whichever side you choose, the same failure recurs: the automation does not know your context.

A workflow classifying support tickets does not know your product's edge cases. An agent triaging them does not know that a certain error is expected during a maintenance window, or that a customer type has a different policy. So both produce confident, generic handling, and someone spends their week correcting it.

Adding that knowledge to a prompt or to a branch condition works for a while and then decays, because the knowledge is scattered, changes, and lives in several people's heads.

RDK covers that layer. Files from local vaults, docs, and code are indexed as encrypted private chunks, and agents search those chunks before querying a model, so the judgment step is grounded in your actual policies, past decisions, and documented quirks rather than in general patterns. Token spend drops 80 to 90 percent on repeated or reference-heavy work because the answer is retrieved instead of regenerated.

Stacked retrieval sets the proportions: a private index over your material answers 40 to 65 percent of queries, the public network adds 15 to 20 percent, and the model handles the remaining 5 to 10 percent. For internal automation, the first bucket is almost everything, since the knowledge that makes the decision correct is knowledge only your organization has.