Two systems, one reliability pattern.
The same rules show up in both builds: commit the intent, keep side effects retryable, and put a human gate where the cost of a mistake is highest.
App architecture
App architecture
App flowrequest path
Clientnext/react
backend · one project, many layers
APInode/go
Domaintypescript/go
DB / Outboxpostgres
Workersretry · idempotent
logsmetricsalerts
What fails and how it recovers
- Duplicate webhooks
- Every delivery carries an idempotency key, so a repeat attempt lands on the same record instead of repeating the effect.
- Provider timeouts
- The outbox keeps the intent. Workers retry with backoff while the original request returns without holding a provider connection open.
- Partial writes
- The domain write and the outbox row commit in one transaction, so a crash cannot leave one without the other.
Agent architecture
Pattern I am buildingAgent architecture
This is the pattern I am building for an outreach agent. It has no production results yet.Read the Lab entry ↗
Agent flowplan path
Brieficp + offer
agent runtime · one project, many layers
Plannerllm, typed steps
Toolssearch · enrich
Approvalhuman gate
Outboxsend · retry
tracesevalscost caps
What fails and how it recovers
- Bad tool output
- Every tool result is schema-checked. A failed check becomes a typed step error instead of a silent branch.
- Runaway cost
- Step and token budgets stop a loop before it spends past the cap, and each run records its cost.
- Unapproved sends
- Outbound actions stop at the approval gate and only enter the outbox after a person accepts them.