← Greenfield DevOps platform

How the pieces work

The architecture shows what connects to what. This page is one level up on three of the boxes: how a model call is routed, how Temporal runs a workflow, and what an agent actually is.

1. Model access: one gateway, local first, cloud as fallback

The profile names the job, never the model, so changing what serves it is configuration plus a benchmark. Every worker pool holds its own key with a spending cap. The fallback is deliberate resilience with a bill attached, which is why the caller reads which model answered rather than trusting the alias. The history, from the Bifrost fork that Dream Team used to the LiteLLM gateway here, and the rules behind the tiers, are on Local or cloud.¹

2. Durable execution: how Temporal runs one work item

A workflow is deterministic orchestration; everything with a side effect is an activity with a heartbeat, a timeout and a retry policy. The workflow id is the item id with a reject-duplicate policy, which is the exactly-once guard. Human gates are signals and escalation is a timer, so a stalled item is impossible by construction: it is either waiting on a named signal, or it has escalated. The same engine runs every long job in the lab, which is the lesson Temporal or it’s a POC.²

3. An agent is a language model inside a harness

The model does the cognitive fill and nothing else. The harness owns checkout, the item branch, the tools, the turn budget, the context window (summarising and pruning as it fills), the verification step, the push, the PR and the telemetry. Tools are a small stdlib registry with path safety and a guard that refuses anything that could reach a real home directory, which is the 2026-07-18 incident written into code. The tier (light, medium, heavy) sets the model profile and the budget; the loop is the same. That is why the May A/B soak found that retry loops, not model choice, were the cost: the loop is where the money goes.³