AI Agent Workflows That Actually Hold Up
Anyone can get an agent to do a task once. The hard part is a workflow that's reliable run after run, across a team. That comes down to one thing: context.
An AI agent workflow is a repeatable, multi-step task an agent carries out — not a one-shot prompt. Building one that works in a demo is easy. Building one that's reliable on the tenth run, with a teammate's agent picking up where yours left off, is the real problem. This page is about what separates the two.
What an agent workflow is
A workflow has structure: defined inputs, a sequence of steps (read, act, verify, hand off), and a source of context the agent draws on. "Review this PR and comment," "triage incoming issues," "scaffold a feature across these services" — each is a workflow when it's defined well enough to run the same way every time.
Why most agent workflows are flaky
The common failure isn't the model — it's that the workflow re-derives everything from scratch each run. The agent doesn't know your team standardized on one pattern, that a past approach was reverted, or who owns the affected code. So it guesses, and the output is inconsistent: great one run, off the next. A workflow built on guesses can't be reliable.
What makes one reliable: shared context
Reliable workflows start from shared, owned context — the team's decisions and conventions, available to the agent the same way every run. When the agent begins each step already knowing the rules, the output stops drifting. And when a second agent picks up a handoff, it reads the same context, so nothing is lost in the pass-off.
First-Tree is where these workflows run.
It's an open-source orchestration platform for teams shipping with humans and agents side by side: agents work alongside you in shared threads, your GitHub issues and PRs become the queue the right agent picks up, and a context tree — an owned, versioned record of your team's decisions and ownership — gives every agent the same memory. Loaded at the start of each run (via a SessionStart hook), that shared context turns one-off agent runs into a repeatable loop — the same decisions, every step, every agent, every handoff.
Single-agent vs multi-agent
Start with one agent and a solid context layer. Reach for multiple agents only when the work parallelizes or needs distinct roles — otherwise you're just multiplying the re-explaining problem. A multi-agent workflow without shared context is several agents each guessing independently. Fix the context first; add agents second.
A workflow you can run today: PR triage
Theory is cheap, so here's a real one. "Triage incoming PRs" is a
workflow most teams run by hand every morning. Define it once as a
command and any agent — yours or a teammate's — runs it the same way.
Save this as .claude/commands/triage-pr.md:
# .claude/commands/triage-pr.md
Triage the open PR I point you at:
1. Read the diff and the linked issue.
2. Check it against our context tree — does it follow the
pattern we standardized on? Did we try this approach before
and revert it? Who owns the modules it touches?
3. Run the test suite; if it's red, summarize why.
4. Post one review comment: a verdict (ship / needs-work),
the owner to tag, and any convention it breaks.
Stop after the comment is posted.Now the workflow is four defined steps with a clear stopping point — not a fresh improvisation each run. Here's what one execution looks like:
- ReadThe agent pulls the diff and the issue it closes — the inputs are explicit, so it never starts from a blank slate.
- Check against contextIt reads the context tree: the convention this PR should follow, the approach the team already rejected, the owner of each touched module. This is the step that makes the verdict trustworthy.
- VerifyIt runs the tests and reads the result instead of assuming green.
- Hand offIt posts one structured comment and tags the owner — a clean handoff a human or another agent can act on.
Run it tomorrow morning on a schedule (/schedule) or in a
loop over every labeled PR (/loop), and the same four
steps execute the same way every time. Swap "triage PR" for "scaffold
an endpoint" or "update the changelog" and the shape holds: explicit
inputs, a context check, a verification, a handoff.
Where workflows break in practice
Once a workflow runs daily, the failures get specific. These are the ones that actually show up — and the fix is almost never "use a bigger model."
| Symptom | Real cause | Fix |
|---|---|---|
| Output is great one run, wrong the next | No stable source of conventions — the agent re-guesses each run | Move the rules into context the agent reads at step one, not the prompt |
| The second agent "loses the plot" after a handoff | State lived in the first agent's prompt, not anywhere the next one can read | Hand off through shared context, not a copied transcript |
| It reverts a fix the team already abandoned | The "we tried this, it broke" decision isn't written down | Record reverted approaches in the context tree so every run sees them |
| It edits code owned by another team without flagging it | Ownership is tribal knowledge, invisible to the agent | Make ownership explicit so the workflow can tag the right person |
| Runs forever or stops half-done | No defined stopping condition in the workflow | Give it a finish line — a goal the agent can check itself against |
Read top to bottom and a pattern emerges: every row is a missing piece of shared, durable context or a missing boundary — never a smarter model. Tighten those two and a flaky workflow becomes one you can leave running unattended.
From a workflow to a team
A reliable workflow is the building block; a team of agents and humans running many workflows off the same context is the goal. That's the AI agent teams model — and pairing it with solid Claude Code practices and a tight CLAUDE.md is how you get there.