Designing an OpenClaw Chief of Staff with Notion Multi-Agent Orchestration

Why one big agent doesn’t work

You’ve probably tried this: write one giant prompt that tells an AI agent to do everything. Read the emails, check the calendar, draft the replies, update the tasks, send the summary. It works for a demo. Then you try it on real work and it falls apart.

The agent forgets instructions halfway through. It uses the most expensive model for every step, even the easy ones. When something goes wrong, you have no idea where. And when you fix it, you have to re-run the whole thing from scratch.

There’s a better way: split the work across a team of small agents, each doing one job, passing results to the next. This post walks through how to design one of these systems in Notion — a “Chief of Staff” agent that handles your daily ops.

The four building blocks

Every multi-agent system rests on four ideas: jobs, contracts, drivers, and logs. Get these right and your agents run like a well-organised team. Get them wrong and it’s chaos.

This pattern comes from Matthias Frank’s guide to multi-agent orchestration in Notion, which is worth reading in full.

1. Jobs: one agent, one task

The first rule is simple. Each agent does one thing. If you find yourself writing “and then” in an agent’s instructions, that’s two agents.

For a Chief of Staff system, here’s how the jobs split:

• Intel Gatherer — pulls in raw info from your inbox, calendar, and notes. Outputs a “today’s raw info” page.
• Triager — reads the raw info and sorts it by urgency. Outputs a prioritised list.
• Briefer — writes a short daily brief with the top 3-5 things that need attention.
• Distributor — creates tasks from the brief and sends a summary notification.

Four agents. Each one easy to test on its own. Each one easy to fix when it breaks.

The bonus: you can use cheap, fast models for the simple steps and save the expensive ones for the step that actually needs heavy thinking. In this example, only the Briefer needs a smart model. The other three can run on something cheap.

2. Contracts: how agents hand off work

A contract is the deal between two agents. It says: “I’ll give you exactly this, in exactly this format, and you can take it from there.”

Two things matter here.

Keep handoffs small. The Intel Gatherer might pull in 5,000 words of raw stuff. But the Triager doesn’t need all of it — it just needs a summary. And the Briefer doesn’t need the summary either, just the top items. By the time the Distributor runs, it’s reading maybe 200 words. This saves money and keeps each agent focused.

Write everything down. Agents can’t ask each other questions later. If Agent A finishes its work and Agent B needs something Agent A didn’t write down, you’re stuck. So every result an agent produces gets saved to a Notion page or property. No exceptions.

3. Drivers: what triggers the next agent

In Notion, agents don’t call each other directly. Instead, they update a status, and the next agent watches for that status to change.

The trick is using a separate status field just for the AI workflow. Your normal status (like “In Progress” or “Done”) stays simple for humans. But you add a second field — call it “AI Stage” — with values for each step:

• Intel Gathered → triggers the Triager
• Triaged → triggers the Briefer
• Brief Ready → triggers the Distributor
• Sent → done

Each agent’s last instruction is: update AI Stage to the next value. That’s how the assembly line keeps moving.

If something goes wrong, the agent leaves a comment on the page explaining what happened and stops. You can see at a glance which step is stuck.

4. Logs: how you actually improve the system

This is the part most people skip. Don’t.

Create a simple database that logs every agent run: which agent ran, when, what it produced, whether it worked. When things break (and they will), you can find the broken step in seconds instead of digging through messages.

Even better, add a quality log. Each day, rate how useful the brief actually was. Over time you’ll see patterns — maybe the Triager keeps missing a certain type of task, or the Briefer is too wordy. You fix the instructions, and the next run is better.

Without logs, you have an AI system you can’t improve. With logs, every failure makes the next version smarter.

Where to start

Don’t build all four agents on day one. Start with two: Gather and Brief. Get a simple daily brief working first. Make sure it’s actually useful before you add the Triager and the Distributor.

This is the 80/20 rule. The simplest version that gives you value is better than a complicated version that doesn’t quite work.

The takeaway

Multi-agent systems aren’t about being clever. They’re about being reliable. Each agent owns one job. Each handoff is clear. Each failure is easy to find. Each retry only re-runs the broken step.

That’s the difference between a cool AI demo and something you actually trust to run in the background while you do other things.