Why These Features?

Gas Town’s architecture explained through enterprise AI challenges

The Problem

You have AI agents. Maybe a lot of them. They’re writing code, reviewing PRs, fixing bugs, adding features. But you can’t answer basic questions:

Who did what? Which agent wrote this buggy code?
Who’s reliable? Which agents consistently deliver quality?
Who can do this? Which agent should handle this Go refactor?
What’s connected? Does this frontend change depend on a backend PR?
What’s the full picture? How’s the project doing across 12 repos?

Traditional tools don’t help. CI/CD tracks builds, not capability. Git tracks commits, not agent performance. Project management tracks tickets, not the nuanced reality of who actually did what, and how well.

The Solution: A Work Ledger

Gas Town treats work as structured data. Every action is recorded. Every agent has a track record. Every piece of work has provenance.

This isn’t about surveillance. It’s about visibility - the same visibility you’d expect from any serious engineering system.

Feature: Entity Tracking and Attribution

The problem: You deploy 50 agents across 10 projects. One of them introduces a critical bug. Which one? Traditional git blame shows a generic “AI Assistant” or worse, the human’s name.

The solution: Every Gas Town agent has a distinct identity. Every action is attributed:

Git commits:    gastown/polecats/toast <[email protected]>
Beads records:  created_by: gastown/crew/joe
Event logs:     actor: gastown/polecats/nux

Why it matters:

Debugging: Trace problems to specific agents
Compliance: Audit trails for SOX, GDPR, enterprise policy
Accountability: Know exactly who touched what, when

Feature: Work History (Agent CVs)

The problem: You want to assign a complex Go refactor. You have 20 agents. Some are great at Go. Some have never touched it. Some are flaky. How do you choose?

The solution: Every agent accumulates a work history:

# What has this agent done?
bd audit --actor=gastown/polecats/toast

# Success rate on Go projects
bd stats --actor=gastown/polecats/toast --tag=go

Why it matters:

Performance management: Objective data on agent reliability
Capability matching: Route work to proven agents
Continuous improvement: Identify underperforming agents for tuning

This is particularly valuable when A/B testing models. Deploy Claude vs GPT on similar tasks, track their completion rates and quality, make informed decisions.

Feature: Capability-Based Routing

The problem: You have work in Go, Python, TypeScript, Rust. You have agents with varying capabilities. Manual assignment doesn’t scale.

The solution: Work carries skill requirements. Agents have demonstrated capabilities (derived from their work history). Matching is automatic:

# Agent capabilities (derived from work history)
bd skills gastown/polecats/toast
# → go: 47 tasks, python: 12 tasks, typescript: 3 tasks

# Route based on fit
gt dispatch gt-xyz --prefer-skill=go

Why it matters:

Efficiency: Right agent for the right task
Quality: Agents work in their strengths
Scale: No human bottleneck on assignment

Feature: Recursive Work Decomposition

The problem: Enterprise projects are complex. A “feature” becomes 50 tasks across 8 repos involving 4 teams. Flat issue lists don’t capture this structure.

The solution: Work decomposes naturally:

Epic: User Authentication System
├── Feature: Login Flow
│   ├── Task: API endpoint
│   ├── Task: Frontend component
│   └── Task: Integration tests
├── Feature: Session Management
│   └── ...
└── Feature: Password Reset
    └── ...

Each level has its own chain. Roll-ups are automatic. You always know where you stand.

Why it matters:

Visibility: See the forest and the trees
Coordination: Dependencies are explicit
Progress tracking: Accurate status at every level

Feature: Cross-Project References

The problem: Your frontend can’t ship until the backend API lands. They’re in different repos. Traditional tools don’t track this.

The solution: Explicit cross-project dependencies:

depends_on:
  beads://github/acme/backend/be-456  # Backend API
  beads://github/acme/shared/sh-789   # Shared types

Why it matters:

No surprises: You know what’s blocking
Coordination: Teams see their impact on others
Planning: Realistic schedules based on actual dependencies

Feature: Federation

The problem: Enterprise projects span multiple repositories, multiple teams, sometimes multiple organizations (contractors, partners). Visibility is fragmented.

The solution: Federated workspaces that reference each other:

# Register remote workspace
gt remote add partner hop://partner.com/their-project

# Query across workspaces
bd list --remote=partner --tag=integration

Why it matters:

Enterprise scale: Not limited to single-repo thinking
Contractor coordination: Track delegated work
Distributed teams: Unified view despite separate repos

Feature: Validation and Quality Gates

The problem: An agent says “done.” Is it actually done? Is the code quality acceptable? Did it pass review?

The solution: Structured validation with attribution:

{
  "validated_by": "gastown/refinery",
  "validation_type": "merge",
  "timestamp": "2025-01-15T10:30:00Z",
  "quality_signals": {
    "tests_passed": true,
    "review_approved": true,
    "lint_clean": true
  }
}

Why it matters:

Quality control: Don’t trust, verify
Audit trails: Who approved what, when
Process enforcement: Gates are data, not just policy

Feature: Real-Time Activity Feed

The problem: Complex multi-agent work is opaque. You don’t know what’s happening until it’s done (or failed).

The solution: Work state as a real-time stream:

bd activity --follow

[14:32:08] + patrol-x7k.arm-ace bonded (5 steps)
[14:32:09] → patrol-x7k.arm-ace.capture in_progress
[14:32:10] ✓ patrol-x7k.arm-ace.capture completed
[14:32:14] ✓ patrol-x7k.arm-ace.decide completed
[14:32:17] ✓ patrol-x7k.arm-ace COMPLETE

Why it matters:

Debugging in real-time: See problems as they happen
Status awareness: Always know what’s running
Pattern recognition: Spot bottlenecks and inefficiencies

The Enterprise Value Proposition

Gas Town is a developer tool - like an IDE, but for AI orchestration. However, the architecture provides enterprise-grade foundations:

Capability	Developer Benefit	Enterprise Benefit
Attribution	Debug agent issues	Compliance audits
Work history	Tune agent assignments	Performance management
Skill routing	Faster task completion	Resource optimization
Federation	Multi-repo projects	Cross-org visibility
Validation	Quality assurance	Process enforcement
Activity feed	Real-time debugging	Operational awareness

For model evaluation: Deploy different models on comparable tasks, track outcomes objectively, make data-driven decisions about which models to use where.

For long-horizon projects: See how agents perform not just on single tasks, but across complex, multi-phase, cross-functional initiatives.

For cross-functional teams: Unified visibility across repos, teams, and even organizations.

Design Philosophy

These features aren’t bolted on. They’re foundational:

Attribution is not optional. Every action has an actor.
Work is data. Not just tickets - structured, queryable data.
History matters. Track records determine trust.
Scale is assumed. Multi-repo, multi-agent, multi-org from day one.
Verification over trust. Quality gates are first-class primitives.

Gas Town is built to answer the questions enterprises will ask as AI agents become central to their engineering workflows.