Why Workflow Automation Is a Trust Problem

A non-programmer wants to hand the system a button that moves real money, and the platform must make that button safe without asking them to read a line of code.

An agent platform is not hard because a model has to pick a tool; that was solved years ago. Spend the design on trust, and read Canonical Events and Routing for the first of the three layers that deliver it.

Objectives:

• restate the agent-platform prompt in plain words, phrase by phrase;
• name the three layers of a strong answer and the incident each prevents;
• list the six guarantees behind a "refund anything under $50" automation.

The prompt reads: "Design an AI agent platform for non-technical users to configure workflow automations across multiple channels." Many candidates hear "AI agent platform" and start drawing a model choosing tools. That spends forty minutes on the wrong thing.

Translated into normal words, the ask is this. A support manager who cannot code says, "When a customer emails asking for a refund under $50, just refund them automatically." The system then does exactly that, safely, whether the request came by email, Slack, chat, or a web form. Everything else in the design is how to make that safe and reliable.

Four phrases carry the prompt.

The platform hands a non-programmer a button that can refund real money, email a real customer, or close a real ticket. They configured it in plain English, not in code they can review line by line. So the real question is how someone who cannot read code can trust the automation to do only what they meant. It must hold even when the model is wrong, the network retries, or the server crashes mid-run.

That is a systems and safety problem wearing an AI costume. The source project makes the point bluntly: it contains no LLM, or large language model, at all. Its "agent reasoning loop" is a fixed, deterministic step sequence. Every property can therefore be proven with fast, reproducible tests, including the negative cases. What that choice costs is covered in Determinism Over Free Text.

Every good answer covers three layers. Each asks one question.

A weak answer talks about Layer 1 and waves at a model doing "reasoning". A strong answer spends most of its time on Layers 2 and 3. That is where real incidents happen: double refunds, an autonomous workflow that skipped a required human check, and a crash that re-runs a completed step.

Warning: do not lead with the model. A design that opens on prompt engineering and tool selection leaves no time for the parts an interviewer is testing. Name the trust problem first, then the three layers, then go deep on Layers 2 and 3.

The user's request, in their own words: "If a customer messages us anywhere asking for a refund and it's under $50, just refund them. Don't bother me for small stuff."

The platform must silently guarantee six things.

1. Whether the message arrived by email, Slack DM, or the website widget, it is normalised into one internal shape before any decision. That is the channel adapters.
2. The workflow fires only for messages about refunds, and if two workflows could match, exactly one wins, deterministically. That is routing.
3. Before it could auto-refund anyone, the workflow went through draft → test → shadow → live, and someone with authority approved it going live. That is staged rollout.
4. "Under $50" is enforced as a real spend-cap check at execution time, not typed into an English prompt and trusted. That is the guardrails.
5. If the refund call is retried, through a flaky network or a duplicate webhook, the customer is refunded once, not twice. That is idempotency.
6. If the server restarts mid-run, the run resumes where it left off rather than restarting and risking a second refund. That is durable, checkpointed execution.

Every guarantee is a component in the architecture. None requires the user to know what an idempotency key is. That is what "the hard part is trust" means in practice: the user states intent, and six components make the intent safe.

The project's scenario is a support tenant, Cascade Robotics, with a ticket-triage workflow: draft a reply, then issue a refund. The question that drives its demo is: "Why didn't Cascade Robotics' $500 refund fire automatically?"

Each answer is a test in the project. Approvals and Spend Caps and Durability and Idempotency build them.

The FDE Handbook's RAG platform, this agent platform, and its delivery framework share one shape on purpose. A named policy returns a Decision(allowed, rule, reason), and deny overrides allow.

The point, stated once for all three: access control, delivery gates, and workflow guardrails are the same kind of problem in three hats. A named rule decides, deny overrides, and the reason is never "because I said so".

Interviewers rarely probe the happy path. Expect two questions: how does a user try a workflow before it is live, and how do you stop a bad one mid-flight? One mechanism answers both: staged rollout plus a hard step and spend budget. They are not two separate features. Staged Rollout covers the first half.

• The prompt, in plain words, is a non-programmer saying "refund anything under $50" and the system doing exactly that from any channel.
• The hard part is trust, not tool selection; the source project proves this by containing no LLM at all.
• Three layers cover the answer, and real incidents live in Layers 2 and 3: retries, crashes, and missed human checks.
• A single automation hides six guarantees, each owned by a component: adapters, routing, staged rollout, spend caps, idempotency, and checkpointing.
• The Cascade Robotics $500 refund was stopped twice by guardrails and could never apply twice because of idempotency.
• Access control, delivery gates, and workflow guardrails share one decision shape: a named rule, deny overrides, and a stated reason.
• Testing before live and stopping a bad run are answered by one mechanism, staged rollout plus hard budgets.

1. Restate the agent-platform prompt in one breath. We are building the safety and orchestration layer between a non-technical user's plain-English intent and a real, destructive action. Whichever channel triggered it, the action runs only when it should, runs exactly once, and survives crashes and retries without surprising anyone.

2. Name the three layers and the incident each prevents. Layer 1, canonical events and adapters, stops channel-specific logic leaking downstream. Layer 2, idempotency and checkpointing, stops double refunds and re-run steps. Layer 3, approvals, spend caps, and staged rollout, stops an action running without the authority it needed.

3. Why did Cascade Robotics' $500 refund not fire automatically, and why could it never fire twice? issue_refund was not on the tenant's autonomous allow-list, and $500 exceeded the $50 spend cap, which refuses rather than clamps. A retry is a no-op because the idempotency key for that action already exists.