Issue 08 · Research basis: 2024 agent design research · GTMhub acceptance method. Historical sources are interpreted for current GTM decisions.
The decision
Choose automation after the workflow can explain what happens when an ordinary dependency fails. A successful demo proves that one path can run. A useful operating system also preserves the request, holds unsafe work and gives an owner a way to recover.
Test the cases the team will actually encounter: missing company identity, duplicate events, an unavailable enrichment provider and an owner who cannot respond.
The design principle behind it
Anthropic's December 2024 guidance on building effective agents recommends simple, composable approaches and adding complexity when it is justified. It distinguishes predefined workflows from systems where the model directs the process.
Our operating interpretation: make the decision and its boundaries explicit before selecting an agent framework. A stable rule with known branches may need a straightforward workflow. More autonomy needs a reason and a way to inspect what it did.
Four cases worth running before launch
Illustrative acceptance tests. These are not a vendor benchmark or production reliability claim.
| Test input | Required behavior | Receipt to retain |
|---|---|---|
| Enrichment times out | Save and route the request using available facts | Failure reason and retry ownership |
| Same event arrives twice | Avoid repeating the accepted action | Stable event identity and prior receipt |
| Account identity is uncertain | Hold the dependent action | Exception owner and resolution status |
| Destination rejects the write | Preserve the original work | Error, recovery path and reconciliation |
For each case, define what may proceed and what must wait. A timeout on optional enrichment need not stop an inbound handoff. An unresolved opt-out check should stop an outbound send.
What to check this fortnight
Pick one workflow close to revenue and list its irreversible actions. For each, identify the evidence required before it runs and the receipt retained after it runs.
Run controlled examples through both the normal and exception paths. Inspect the destination where practical; a successful HTTP response is not always proof that the business event was accepted correctly. Reconcile what was proposed, attempted, accepted, held and retried.
Decide who can pause the workflow and who resolves the failure. Give that person the original inputs and a readable explanation. Recovery should not depend on somebody remembering which browser tab contained the error.
One tool decision
The stack we run organizes tools by the job. Start with the existing CRM or a simple connector when that meets the acceptance criteria. Add another tool for a documented capability gap and verify that gap with your own sample.
A synthetic logic test can show whether a rule behaves correctly. It cannot establish a vendor's coverage, deliverability, uptime or performance on your company's data.
Use this next
Use the inbound-routing example to inspect a held identity and an unavailable dependency. Then record your own workflow's acceptance cases in the decision register, with the owner and the evidence needed to proceed.
The question before launch: when this workflow has its worst ordinary day, will the buyer's request still be safe and somebody know what to do?
Publication and source record
Published on GTMhub: . Last reviewed: .