Automation used to mean scripts and rules: if this happens, do that. It now also means AI agents that read, classify, draft and act across systems. That changes the question. It is no longer "can this be automated?" but "which part of this work should a rule do, which part an agent, and which part a person?" — and that can only be answered once the work itself has been designed.
Most disappointing automation projects skip that step. They speed up a process nobody designed and get a faster version of the same problem. This topic covers how to automate well: choosing what to automate first, designing the process before the tool, connecting systems, and keeping people in charge of the decisions that matter.
Questions this topic answers
- Which of our workflows should we automate first, and which should we leave alone?
- When is a simple rule enough, and when does the work need an agent?
- Which actions should wait for a person, and how do we keep that fast?
- How do we stop an automation becoming another system to babysit?
- How will we know whether it helped?
Start here
- Why automation without process design fails — the pattern behind most disappointing automation, and the one-page design that prevents it.
- Choosing the First Automation — a decision framework for value, feasibility, risk and readiness, ending in one shaped mission.
- When a business should not build an AI agent — when a rule, a form or a fixed process is the better tool.
- Why a good intake system changes the quality of every downstream workflow — every automated step inherits what intake got right or wrong.
- Designing Event-Driven Business Operations — Field Guide 021: letting events, not people, move work between systems and agents.
- Human Approval Patterns for AI Agents — Field Guide 014: where a person must decide, and how to keep it fast.
For the problem as most businesses describe it, see Manual operations.
Key ideas
- Process before tool — design the trigger, outcome, owner, decisions, exceptions and approvals before choosing what automates them.
- Rule, agent or person — deterministic automation for clear rules, agents for reading and judgement-heavy preparation, people for consequential decisions.
- Remove before you automate — delete the steps that exist only because of old constraints, or the automation makes the workaround permanent.
- Exceptions are the process — much of the cost and risk sits outside the happy path; decide where each exception goes.
- Safe to repeat — automated steps will be retried, so a retry must never send the email twice or pay the invoice twice.
- Baseline first — measure the process before changing it, or you will never know what the automation achieved.
- Earned autonomy — Observe, Assist, Operate, Optimize: each step up is a person's decision, made on evidence.
Who knows this topic
The Guild's approach to manual operations divides the work into four roles, each with a Human Wizard checkpoint:
- Athena — receives the work, structures it and routes it to the right agent or person.
- Hephaestus — builds and maintains the connections between your tools.
- Sentinel — keeps every action inside policy and escalates what needs a person.
- Oracle — measures volumes, exceptions and time saved, and reports what changed.
Ares, the Guild's execution agent, runs workflows and triggers automation chains so that decisions turn into action.
Where this knowledge is put to work
AI Agent Development turns one critical workflow into a governed agent. Managed operations runs the workflows, systems and agents after launch, with continuous monitoring and accountable human escalation. The Guild Assessment asks what you want to change and shows where the Guild would start; a Human Wizard then replies with a written brief.
Which work would you take off your team's plate first? Start there.
