# Yeeted in AI development loops

The Markdown copy of <https://yeeted.ai/docs/agent-loop.html>.

Yeeted isn't just reachable by an agent: it's designed to be the deploy-and-verify half of an autonomous coding loop. Every tool result is structured for a model to act on, so an agent can build, ship, test, diagnose, fix, and promote without a human unblocking it.

## The loop

The intended cycle, all over MCP:

```
// the agent's iteration cycle
validate      // dry-run: stack detection, port, missing-database warnings, before any build
deploy        // to development (default): a safe test space, seeded from prod data on Small Business and up (after the beta)
smoke_test    // platform-side HTTP probes against the live dev URL
diagnose      // one internally-consistent verdict + recommended_action when anything looks off
promote       // the EXACT tested image goes live under its yeeted.yaml; health-gated blue/green
rollback      // retained git hash: app only; data-bearing production checkpoint: data may restore too
```

### Blameless failure classification

The most expensive agent failure mode is misattribution: a platform hiccup that the agent "fixes" by
rewriting healthy code. Every Yeeted failure carries two machine-readable fields:

```
{
  "cause_category": "build_error | crash | health_check | image_missing | platform | dependency",
  "self_fixable":   true | false
}
```

`self_fixable: false` means *do not touch the app*: retry or wait, it's ours.
When it's the code, the failure includes the file and line parsed from the stack or compiler output,
so the agent's next edit is aimed, not guessed. Errors are also flagged *new since the last
deploy*, which is the signal for "roll back" versus "fix forward."

### Safe retries, safe batches

Deploys are idempotent by content: re-sending identical files returns the existing deploy instead of
stacking a second build, so an agent retry loop can't stampede the pipeline. For batch work,
`project_context` reports the platform's live capacity headroom
(*"development: room for ~6 more instances"*) so an agent can pace itself, and a deploy sent
with `queue_on_capacity: true` parks on a capacity miss and places automatically when a slot
frees (bounded wait), instead of failing the tail of the batch.

### Memory for the loop

Every deploy is a numbered version with its source snapshotted. `versions_list` is the
agent's deploy log, `whats_changed` diffs any two versions, and `checkpoint`
names a known-good state to return to. A fresh agent session starts with one
`project_context` call and has the whole picture: status, URL, versions, databases, secret
names, health, and capacity. The code itself is a git repository the agent can read and edit over MCP;
see [Version control](https://yeeted.ai/docs/version-control.md).

Wiring Yeeted into CI or a custom agent runtime instead of an interactive session?
Create an OAuth credential in the dashboard and drive the same MCP tools from your pipeline: the
contract is identical.