The G8 Method
How to run automation well.
G8 is a tool, but a tool needs a method. This is the opinionated playbook we build the product around — six principles for turning a process into automation you can trust.
Describe before you automate.
Automation is only as good as the understanding behind it. Write the process down in plain language before a single step runs — the act of describing it is where most of the mistakes get caught.
Write it the way you'd explain it.
Name the roles, the hand-offs, the tools touched, the approvals, and the outputs. If you can't explain a step in a sentence, an agent can't run it safely.
Be specific about the edges.
Define what success looks like, what to do on failure, and which steps are sensitive. Vague processes produce vague automations.
Let the blueprint correct you.
Read the compiled blueprint critically. The risk and automation levels are a mirror — if they look wrong, your description was wrong.
Contract everything.
An unbounded agent is a liability. Before a flow runs for real, decide explicitly what it may do, what it must never do, and where it has to stop and ask.
Allow narrowly.
List only the actions the flow actually needs. A short allow-list is easier to reason about — and to defend — than a broad one.
Block deliberately.
Name the actions the flow must never take, even if a step suggests them. Blocks are your guardrail against a model improvising past its mandate.
Scope the data.
Grant the minimum read and write access the process requires. The contract is the place to enforce least privilege, not an afterthought.
Simulate before live.
A flow should earn its way to production by passing a dry run you have actually looked at. Simulation is cheap; a bad live run is not.
Dry-run with no side effects.
Simulation walks every step and shows the expected output without sending, posting, or writing anything. Use it as the default first run.
Read the preview, don't skim it.
The value of a simulation is in being reviewed. Trace each step against your intent before you flip the flow live.
Keep humans on risk.
Automate the routine; gate the consequential. The goal is not to remove people — it is to spend their attention only where it matters.
Gate the irreversible.
Put an approval in front of any step that spends money, sends external messages, or can't be undone. The run pauses and waits for a decision.
Resume cleanly.
An approved run continues from where it paused without losing step state. Humans stay in the loop without becoming the bottleneck.
Monitor, then iterate.
A flow is not done when it ships — it is done when it is observable. Watch how it behaves and improve it with evidence, not guesses.
Watch the right four numbers.
Run volume, success rate, errors, and runs waiting on a human tell you almost everything about a flow's health at a glance.
Drill in on failure.
When a run fails, trace it to the step. Fix the description or the contract — not the symptom — and re-simulate.
Govern at scale.
One good flow is a project. A hundred is an operating system. Reuse, idempotency, and clear ownership are what keep the second case from collapsing.
Reuse instead of rebuilding.
Pull from the agents library and templates so common steps are contract-bound and battle-tested, not reinvented per flow.
Make triggers idempotent.
Under load, the same event can arrive twice. Idempotency keys and single-flight runs keep automated triggers from double-firing.
Right-size the plan.
Match capacity and capability to the tier your workspace actually needs, and keep entitlements aligned with how much you run.