Bottega is a coding agent orchestrator that shipped 1,000 user stories internally before going open-source. The team behind it claims 100% of their production code has been written by agents for eight months. That claim matters less than the orchestration patterns they built to make it work.
Most agent frameworks optimize for demos. Bottega optimized for a team that needed to ship features daily without human intervention in the implementation loop. The result is a workflow harness that separates planning, execution, review, and deployment into discrete agent-managed phases with explicit handoffs.
Architecture: Pipeline Stages and Model Switching
Bottega treats a user story as a pipeline with four stages:
- Planning: Decompose the story into subtasks and file modifications
- Implementation: Generate code changes across multiple files
- Review: Run static analysis, tests, and code review
- PR Management: Handle CI failures, merge conflicts, and merge triggers
Each stage can run a different model. The orchestrator picks the model based on task complexity and cost. A typical flow might use Claude Opus for planning, Sonnet for implementation, a cheaper model for review, and an open-source model for PR babysitting.
The team discovered this by accident. A bug defaulted all subprocesses to Sonnet 3.7 for two weeks. They shipped dozens of tasks before noticing. Output quality stayed consistent because the workflow harness constrained the problem space enough that model choice mattered less than process rigor.
# Simplified stage configuration
stages = [
{
"name": "planning",
"model": "claude-opus-4.6",
"temperature": 0.3,
"max_tokens": 8000,
"retry_limit": 2
},
{
"name": "implementation",
"model": "claude-sonnet-3.7",
"temperature": 0.2,
"max_tokens": 16000,
"retry_limit": 3
},
{
"name": "review",
"model": "codex-latest",
"temperature": 0.1,
"max_tokens": 4000,
"retry_limit": 1
},
{
"name": "pr_management",
"model": "deepseek-coder",
"temperature": 0.0,
"max_tokens": 2000,
"retry_limit": 5
}
]State Management and Conflict Prevention
Multi-agent coding workflows fail when agents modify the same file concurrently or when one agent’s output invalidates another’s assumptions. Bottega solves this with a file-level locking mechanism and a dependency graph.
The planning stage outputs a task graph where each node represents a file modification and edges represent dependencies. The orchestrator schedules agents to work on independent files in parallel and serializes dependent modifications.
State lives in three places:
- Task graph: Tracks which files need changes and their dependencies
- File locks: Prevents concurrent modifications to the same file
- Execution log: Records agent outputs, errors, and retry attempts
When an agent completes a subtask, the orchestrator validates the output against the task graph. If the agent modified files outside its scope or failed to modify required files, the orchestrator flags the deviation and either retries or escalates to human review.
Failure Recovery and Retry Logic
Bottega’s retry logic is stage-specific. Planning failures get two retries with increased temperature. Implementation failures get three retries with the same temperature but different prompts. Review failures trigger a single retry, then escalate to human review.
The orchestrator distinguishes between transient failures (API timeouts, rate limits) and semantic failures (agent produced invalid code, missed requirements). Transient failures trigger immediate retries. Semantic failures trigger prompt refinement or model switching.
| Failure Type | Detection Method | Recovery Strategy | Escalation Threshold |
|---|---|---|---|
| API timeout | HTTP 504 or connection error | Exponential backoff, same model | 3 retries |
| Rate limit | HTTP 429 | Switch to alternate provider | 2 retries |
| Invalid syntax | Static analysis failure | Retry with syntax error context | 3 retries |
| Test failure | CI pipeline failure | Retry with test output | 2 retries |
| Scope creep | File diff outside task graph | Revert and retry with constraints | 1 retry |
| Requirement miss | Human review rejection | Escalate to planning stage | Immediate |
The team found that most failures cluster in the implementation stage. The planning stage rarely fails because the task decomposition problem is simpler. The review stage fails often but cheaply, so aggressive retries are acceptable.
Observability and Debugging
Bottega exposes three debugging surfaces:
- Execution timeline: Shows which agents ran when, on which files, with which models
- Diff viewer: Displays file changes at each stage with blame attribution to specific agents
- Prompt log: Records the exact prompts sent to each model, including context and constraints
The timeline view is critical for diagnosing why a task stalled. If an agent is waiting on a file lock for 10 minutes, the timeline shows which other agent holds the lock and why.
The diff viewer solves the “who broke this” problem. When a test fails after multiple agents touched the same codebase, the diff viewer shows which agent introduced the breaking change and which prompt generated it.
The prompt log is the escape hatch. When an agent produces unexpected output, the log shows exactly what context it received. The team uses this to refine prompts and add constraints.
Multi-Provider Support and Cost Optimization
Bottega added support for Codex, OpenCode, and open-source models after Anthropic raised Claude pricing. The orchestrator treats providers as interchangeable backends with different cost and latency profiles.
The cost optimization strategy is simple: use the cheapest model that can complete the task within the retry budget. Planning uses expensive models because retries are rare. PR management uses cheap models because retries are frequent and the task is mechanical.
The team tracks cost per user story and uses it as a feedback signal. If a story costs more than expected, they investigate whether the planning stage over-decomposed the task or whether the implementation stage burned retries on a hard problem.
When to Use Bottega
Bottega fits teams that:
- Ship features frequently enough to justify orchestration overhead
- Have a test suite and CI pipeline that can validate agent output
- Can tolerate occasional human review when agents fail
- Want to mix models based on cost and task complexity
Bottega does not fit:
- One-off scripts or prototypes where setup cost exceeds value
- Codebases without tests, where agent output is hard to validate
- Teams that need deterministic builds, where agent variability is unacceptable
- Projects where code review is a learning exercise, not a quality gate
Technical Verdict
Bottega is production-hardened orchestration plumbing for teams that already trust agents to write code. The value is not in the agent capabilities but in the workflow harness: task decomposition, file-level locking, stage-specific retry logic, and multi-provider switching.
The claim that model choice matters less than process rigor is the most interesting takeaway. If a tight harness can make Sonnet perform like Opus, the implication is that most agent failures are workflow failures, not model failures.
Use Bottega if you need to scale agent-written code beyond one-off experiments. Avoid it if you are still figuring out whether agents can write code at all. The orchestration overhead only pays off when the baseline workflow is already proven.