What we build

Seven pillars, one discipline.

Every pillar comes back to the same thing: how the system is designed, not which model we called.

Flagship

1. Agent reliability & AgentOps hardening

The flagship. Reliability designed into the harness, not patched.

Most agent stacks are built prompt-first and break the first time the real world pushes back. We treat reliability as architecture. The tactics below are the proof.

  1. Idempotency tokens

    a retry that lands twice counts once

  2. State checkpoints before any stateful operation

  3. Connector layer

    circuit breakers, retry budgets, read-vs-write permissions

  4. Cost guards

    daily budget, soft alert 70%, hard kill 95%

  5. Reliability SLIs

    success rate, retry rate, p95 latency, cost-per-output

  6. Progressive tool access

    read-only first, write earned

2. Autonomous AI departments

The harness at department scale — an orchestrator governing a depth-4 agent tree.

One orchestrator delegating to specialist sub-agents, each with its own memory, model config, and scoped tools. What makes it trustworthy is the design: agents loosely coupled through a shared file bus, an idempotent dispatcher, eval-gated model selection, self-hosted observability, human approval gates.

Flagship: a 24/7 content department turning one chat brief into scheduled, published multi-platform output. Fourteen core specialist lanes fan into depth-4 leaf agents under one orchestrator.

Orchestrator dispatches over a Shared file bus to depth-4 agent tree (extract, route, draft, review, publish, and more), whose output passes through a human approval gate to Published content; gated by idempotent dispatch and eval-gated routing.
Orchestratorcoordinator
Dispatch / routing
  • idempotent dispatch
  • eval-gated routing
Shared file bus
  • extract
  • route
  • draft
  • review
  • publish

depth-4 agent tree

Human approvalgate
Published contentmulti-platform

3. AI agents & custom MCP servers

The tooling the ecosystem runs on — plugins and custom MCP servers.

A single-orchestrator-plus-N-tools architecture — each tool with its own prompt, integration, and memory; the orchestrator holds the state so failure stays recoverable. When the tool you need does not exist, we build it. goalkeeper is a Claude Code plugin whose subagent judge gates completion against a Definition of Done; reaper-mcp is a public MCP server others run, alongside custom MCP servers we build for agent-driven automated testing and ML-training in DAW and video-editor environments.

4. Multi-model routing & cost optimization

Pay for the model the task earns, not your default.

Capability-tiered routing: match each task to the cheapest model that does it well, fail over across providers, share memory. We tier Claude Opus, Sonnet, and Haiku — Haiku for cheap reformatting, Sonnet for reasoning, Opus only where it earns it. We pin the architecture, not the version, behind the Vercel AI SDK — the next model is a config change.

5. Document → structured extraction pipelines

Messy documents in, schema-validated data out — with citations.

Spec, quote, and proposal PDFs and DOCX in; schema-validated fields out, each citing the source page. Layout-aware parsing preserves tables. Built on Unstructured plus a frontier vision model, enforced through the tool-use API so output is schema-valid before the UI.

6. Full-stack AI SaaS

The boring, shippable default stack.

Next.js on Vercel, Supabase (Postgres, Auth + RLS, Edge Functions, pgvector), Stripe (Checkout, webhooks, subscriptions, credit systems). On top: streaming AI chat, tool-calling, structured output, OAuth, background jobs, admin dashboards. The stack that turns an AI feature into a product.

7. RAG & memory systems

Retrieval and memory built for production.

Chunking, embeddings, and retrieval that hold up under real load. A three-layer memory model: episodic in Redis, semantic via RAG over Pinecone / Weaviate / pgvector, procedural as explicit JSON/YAML config — deliberately not embeddings, because some knowledge should be exact. Persistent agent memory through Obsidian and a Memory MCP, tone profiles refined by diffing the human reply against the draft.

Our differentiator

A research-grade ML edge.

Original neural audio codecs and score-based diffusion models, trained from scratch in PyTorch and benchmarked against published baselines. That depth is the difference between reasoning about how a model behaves and calling an API and hoping — it is why we can tell you where a model will fail.

The named stack

What we build on.

Specific tools, chosen on purpose.

Languages

  • TypeScript / JavaScript
  • Python
  • Rust
  • C++
  • SQL

AI / LLM

  • Claude API (primary)
  • OpenAI GPT-5.5
  • Google Gemini
  • OpenRouter
  • Ollama
  • LangChain / LangGraph
  • Vercel AI SDK
  • Claude Code
  • MCP

Web & app

  • Next.js
  • React
  • Express
  • FastAPI / Flask
  • Electron
  • Tailwind
  • Zustand

Data

  • Supabase / Postgres
  • Redis
  • MongoDB
  • Pinecone / Weaviate / pgvector
  • Snowflake / Databricks

Infra & deploy

  • Vercel (primary)
  • AWS
  • GCP
  • DigitalOcean
  • self-hosted VPS
  • Apple Silicon for local agent hosting
  • Docker
  • launchd

Orchestration & automation

  • n8n
  • Make.com
  • Inngest
  • Bull
  • Playwright / Puppeteer
  • Firecrawl

ML

  • PyTorch
  • Transformers
  • RunPod
  • Sentry / PostHog
  • experiment tracking

Common questions

The reliability questions buyers actually ask.

What is AgentOps?

AgentOps is the engineering discipline of making AI agents reliable in production — the harness around a model: state checkpoints, idempotent tool calls, retry budgets, cost guards, evals, and observability. Bonfire treats it as the flagship of every build, where reliability is measured (tool-call success rate, retry rate, p95 loop latency, cost-per-output), not asserted.

How do you make an AI agent reliable in production?

We architect the harness so failure is recoverable by construction: state is checkpointed before any side effect, every tool call carries an idempotency token, integrations sit behind a permissioned read-versus-write layer with circuit breakers and retry budgets, and a recovering agent resumes from the last good step instead of repeating work.

What is an idempotency token in an agent system?

An idempotency token is a stable key — for example a hash of agent_id + step + payload — attached to a tool call so that if an agent retries after a side effect already landed (an email sent, a row written, a payment made), the system recognizes the duplicate and skips it. It is the fix for the most common silent failure in prompt-first agents.

Do you build custom MCP servers?

Yes. We build Model Context Protocol (MCP) servers when the tool an agent needs does not exist. Our open-source reaper-mcp (58 tools, on PyPI) is public, installable proof; we also build custom MCP servers for agent-driven automated testing and ML-training in DAW and video-editor environments.

What does “the harness is the product, not the prompt” mean?

The model is the easy part. The harness is everything that lets it work safely: tool definitions, permissions, memory, state, checkpoints, evals, recovery, and observability. That scaffolding — not the prompt — decides whether an AI system survives production. It is what separates an AI system from an AI feature.

Not sure which pillar your problem falls under?

Most engagements touch three or four. Tell us what is breaking; we will map it.