Designing complex flows

A well-designed complex workflow is layered: a clear trigger, focused agent steps, deliberate pauses for human input, and explicit paths for when things go wrong. Build it in that order and test the full loop before it touches live traffic.

Design in layers

Before adding pauses or error handling, map the simplest version. What fires it: a ticket, chat, schedule, or webhook? What must the agent do, broken into distinct phases: gather information, act on it, confirm completion? And what does success look like as a concrete end state?

Then avoid one enormous agent step that tries to do everything. Give each phase its own step with its own goal, skills, and error path: a gather step (look up data in a connected system, search the knowledge base, ask the requester), an act step (draft a document, send a message, create a ticket), and a confirm step (post a summary, close the task, update the original record). Smaller steps are easier to debug and easier to change when the process shifts. This is what Advanced mode (canvas editor) is for; stay with a single step until the process outgrows it.

Add pauses where humans belong: a ticket reply wait for input from someone already on the ticket, an approval before anything irreversible, a data-gathering sub-agent for someone outside the thread, and a scheduled wait when time needs to pass, for example chasing 48 hours after a notification.

Delegating to sub-agents

When a step requires a back-and-forth conversation with a third party, delegate it rather than loading that complexity onto the main agent. The main agent stays focused on orchestrating; the sub-agent handles one specialized task with its own restricted skill set, and neither is overloaded with tools it does not need.

1. Configure delegatable skills. On the main agent step, list the skills a sub-agent may receive, separate from the main agent's own skills. Usually this is just the data-gathering skill.
2. The main agent hands off a bounded task. It gives the sub-agent specific instructions for what to gather and what counts as complete, and the main workflow pauses.
3. The sub-agent runs. It may pause itself for outreach and replies.
4. The result comes back. The sub-agent's summary, and any files it produced, pass to the main agent, which resumes with full context.

Delegation is serial: one sub-agent runs at a time, and the parent waits for it to finish before it can delegate again. Two independent conversations happen one after the other, so plan wall-clock time and timeouts accordingly. Sub-agents cannot delegate further; delegation is one level deep by design. If you find yourself wanting deeper nesting, split the process into two separate workflows.

The sub-agent security model

Sub-agents run in a restricted context. They see only the explicitly listed delegatable skills, never the main agent's full toolset; parent workflow context and files are not shared unless the parent passes them explicitly; and knowledge base or employee data access exists only if the delegatable skill includes it. Sub-agents are scoped to the same organization as their parent, and they cannot trigger approval flows: any tool that requires human confirmation is unavailable to them, so approval-gated actions must live on the main agent.

The most restricted mode applies when the only delegatable skill is Agentic data gathering: the sub-agent then cannot access the knowledge base, employee records, or file browsing at all. Since these agents contact people outside your organization (vendors, contractors, candidates), the restriction ensures Harriet cannot relay sensitive internal data to third parties even if the instructions attempted it. Audit the delegatable skills list with the same rigor as the main agent's skills, and check the allowed-in-sub-agent setting on MCP tools after adding new connectors. Sub-agent runs appear in the workflow run history alongside the parent, so check both when debugging.

Error paths and testing

• Write on error instructions for every agent step; "post an internal note and assign to the inbox owner" is a safe default.
• Set a timeout on every sub-agent step so the main workflow never waits indefinitely, and let the on-error instructions say what happens after a timeout.
• Keep instructions in each step concise; long, ambiguous instructions are a leading cause of unexpected agent behavior.
• Test the full loop end-to-end in a pilot inbox before enabling on live inboxes, paying particular attention to the pause and resume paths.