Life After BotHuddle: The Wild West of /teamwork

Antigravity/teamworkGovernanceTechnical Debt
Series Context: NeuroHub Engineering chronicles our journey building the first AI-native operating system for neurodiversity care. This post is part of a deep-dive series exploring our technical challenges scaling an autonomous multi-agent orchestration framework (BotHuddle) to write and test production React code.

Moving from a cloud-heavy agentic orchestration model to local execution has been one of the most defining and turbulent transformations for NeuroHub's engineering team. As we detailed extensively in The Pivot, we made the strategic call to pause BotHuddle.

To understand why this was so impactful, we have to look at what BotHuddle gave us. BotHuddle operated as an incredibly sophisticated multi-agent consensus engine that worked remarkably well—far better than any off-the-shelf agent toolchain available. Agents participated in an LMSR (Logarithmic Market Scoring Rule) prediction market to bid on implementation paths for any given feature request. The market assigned probabilities to the success of architectural decisions, staking tokens on proposed implementations and naturally penalizing duplicate logic or brittle patterns. However, the flat fixed cost of maintaining the underlying non-AI infrastructure 24/7—dedicated Forgejo Git instances, Zulip servers, VPC NAT gateways, and continuous event relays—was simply too steep for a lean startup team to carry before reaching the organizational size to fully amortize it. We decided to pause BotHuddle until our engineering organization expands, archiving its proven architecture for the future.

Our shift to Antigravity's /teamwork slash command changed everything. It slashed our orchestration costs to near zero by moving the heavy lifting to local execution and dramatically accelerated feature delivery. By running autonomous agent clusters locally on our developer machines, a single slash command now spawns local subagents that instantly partition tasks, analyze the codebase, and refactor code directly:

/teamwork Refactor document parsing pipeline for strict typed JSON in Next.js

This local-first paradigm shift felt like removing a restrictor plate from a race car. The latency dropped from minutes to milliseconds, and our developers were shipping complex features at a pace we had never seen before. However, the honeymoon phase was short-lived. We quickly realized that in abandoning BotHuddle, we had also abandoned its strict, programmatic architectural governance. We traded exorbitant cloud costs for a completely different kind of tax: a compounding wave of architectural technical debt.

The Missing Guardrails and the Path of Least Resistance

Without the economic incentive structure of the BotHuddle prediction market, our local Antigravity agents reverted to the path of least resistance. Optimizing purely for local, immediate task completion, they started making decisions that were highly efficient in isolation but catastrophic for our global architectural integrity.

Instead of navigating the codebase to import our established src/lib/date-utils.ts, or leveraging our carefully crafted DynamoDB Single-Table Design patterns, agents began injecting ad-hoc functions, localized data fetching, and duplicate utilities directly into Next.js UI components.

In a Single-Table Design, entities like Users, Receipts, and Workflows all live in the same DynamoDB table, distinguished by precise PK (Partition Key) and SK (Sort Key) patterns. Unconstrained agents, lacking a holistic view of the schema, would frequently hallucinate secondary indexes or attempt to perform deeply inefficient Scan operations to retrieve related data, ignoring the carefully constructed GSI (Global Secondary Index) overloading we had put in place. They would try to query a Receipt by a non-indexed field, rather than traversing the established graph from the User partition.

// Ad-hoc spaghetti generated by unconstrained local agents
function calculateReimbursementAdHoc(amount: number) {
    return Math.round(amount * 1.05 * 100) / 100; // Hardcoded compliance rule!
}

When autonomous agents make this specific mistake hundreds of times across a massive Next.js Static Export application, the resulting technical debt is staggering. We started finding critical business logic—rules that explicitly belonged in our centralized compliance engine—leaking directly into route handlers and client-side React components. The codebase was fraying at the edges, becoming a patchwork of isolated, agent-generated silos that ignored our broader system design.

Adapting the NeuroHub Stack to Autonomous Agents

To rein in the chaos without sacrificing the blistering speed of the /teamwork workflow, we had to deeply integrate governance directly into our specific technology stack: AWS Amplify, DynamoDB, AppSync GraphQL, and Next.js.

Because we deliberately do not use Docker, Kubernetes, or containerized microservices, we couldn't rely on network boundaries or service meshes to sandbox agent behavior. Everything in our architecture happens in a monolithic repository outputting a Next.js Static Export, powered exclusively by a strictly typed AppSync GraphQL API.

Our first major defense mechanism was introducing rigorous AST-based (Abstract Syntax Tree) validation rules that run as Git hooks. We configured these hooks to scan every commit generated by an agent. If an agent attempts to write raw DynamoDB queries inside a React component rather than modifying our AppSync VTL (Velocity Template Language) resolvers or src/lib/orm, the commit is instantly blocked and rejected. Agents are now forced to route all data mutations through our established GraphQL layer, preserving our data integrity.

Furthermore, we had to address complex state synchronization and event propagation. When local subagents spun up to handle massive refactors involving our event-driven architecture, they often struggled to correctly map out our AWS EventBridge and SQS topologies. Left to their own devices, agents would attempt to write directly to unrelated DynamoDB tables to trigger side effects, entirely bypassing our decoupled event buses. To solve this, we built custom Antigravity skills (such as skill-amplify-events) that inject explicit context about our event schemas directly into the agent's prompt during execution. This guarantees that agents correctly publish strictly typed domain events to EventBridge, rather than attempting to directly update unrelated records and creating tight, fragile coupling.

Search, Embeddings, and the Relentless Pursuit of Cost Engineering

Cost engineering didn't stop with the death of BotHuddle. We encountered similar, massive financial friction with our search infrastructure. Initially, we relied heavily on Postgres with the pgvector extension for vector similarity search. It was a robust solution, but as our document vault grew to encompass millions of medical and financial records, the RDS (Relational Database Service) bills became completely unjustifiable for our scale.

We aggressively pivoted away from Postgres entirely, fully embracing a serverless paradigm. Today, we generate all embeddings via the Gemini API and index them entirely in-memory using Orama during the Next.js static build process. The serialized indexes are then persisted directly to S3 and served via our CDN. This serverless, edge-friendly approach aligns perfectly with our Amplify backend and eliminated thousands of dollars in monthly database costs.

However, we had to explicitly train our Antigravity agents to understand this architectural constraint. In the early days of /teamwork, agents would frequently try to solve complex search queries by proposing a Postgres schema migration or a Prisma schema update—because that is what they had learned from the broader internet. We hardcoded rules into our environment: any agent that proposes a Prisma migration or a SQL script will instantly fail our CI pipeline and be penalized in its execution loop.

Taming Visual Regressions locally

Perhaps the most fascinating and frustrating challenge of the /teamwork era was visual validation. With multiple subagents generating and refactoring UI code concurrently, visual regressions spiked dramatically. As we discussed in our earlier post, Visual Testing and Local LLM Migration, cloud-based visual diffing services were simply too slow for an autonomous, local agent loop.

We brought visual testing entirely locally, utilizing lightweight local LLMs to evaluate UI state and catch regressions before they were ever committed. However, this introduced a severe hardware bottleneck. Processing massive fullPage: true Playwright screenshots concurrently caused our developers' standard MacBook Pros to instantly crash due to VRAM Out-Of-Memory (OOM) errors. The agents were moving so fast that they would trigger dozens of visual tests simultaneously, completely overwhelming the local GPU.

We emphatically do not crop images to solve this. In the healthcare domain, full context is absolutely critical for accessibility, compliance, and holistic layout validation. Cropping a screenshot might hide a critical overlapping medical warning banner at the bottom of the page.

Our solution was beautifully simple but highly effective: an HTTP Mutex Queue running locally on port 8002.

// Local HTTP Mutex Queue for VRAM safety
async function enqueueScreenshot(buffer: Buffer) {
  return await fetch('http://localhost:8002/process', {
    method: 'POST',
    body: buffer,
    headers: { 'X-Mutex-Lock': 'vram-guard' }
  });
}

This strict local queue acts as a traffic cop for the GPU. It ensures that only one fullPage image is processed by the local LLM at any given time. This HTTP Mutex wasn't just a simple lock; we implemented a priority queue within the port 8002 service. If a developer manually ran a test, it would jump the queue ahead of background agent validations. This ensured the developer experience remained snappy while the agents churned through their comprehensive visual regression suites in the background, fully utilizing the GPU without causing a system panic. By queuing the visual validation requests, we completely eliminated the VRAM crashes while still maintaining the incredible autonomy and overall speed of the /teamwork agents. It added a few seconds of latency to the tests, but provided infinite stability.

Embracing the Wild West

Life after BotHuddle is undoubtedly the Wild West. Removing the rigid, costly cloud orchestration unleashed unprecedented velocity, allowing us to leverage AWS Amplify, DynamoDB, and Next.js at a blistering pace. Our developers are happier, our features ship faster, and our cloud costs are a fraction of what they used to be.

The profound trade-off is that we can no longer rely on external markets or cloud orchestrators to enforce our architecture. We must continuously encode our architectural constraints—whether it's our Orama embedding strategy, our strictly typed EventBridge schemas, or our local VRAM mutex queue—directly into the tooling, the Git hooks, and the agents' context windows.

The frontier is chaotic, and managing autonomous agents requires a fundamentally different mindset. But for teams willing to build the right guardrails and embrace the chaos, the productivity gains are absolute magic. We are no longer just writing code; we are building the tracks just ahead of a runaway train, and we wouldn't have it any other way.