Brekfuz is backed by Pareto Holdings, Pear VC, Z Fellows, Cory Levy and Collective Global. As its founding engineer I built the whole agent platform, end to end: four production services on AWS, memory agents that have handled 100,000+ requests, twelve stream queues with dead-letter recovery, and the infrastructure under all of it.

  • 100,000+Requests handled by the memory agents
  • 213,761Production requests in 14 days
  • 25,300+Automated tests across Brekfuz and Breken
  • 103Tables under forced row-level security
  • 2,100×Cut in hot-path graph query cost
  • 392kRelationships in production memory

What it is

Ask a question in Slack and Brekfuz answers in the thread, with sources, from everything the company already has: Slack, Gmail, Calendar, GitHub, Jira, Linear and meeting notes. The part of the answer the channel is cleared to read posts in public. The rest reaches the asker by DM. Nothing crosses that line.

When nobody wrote the answer down, Brekfuz knows who holds it. It routes the question to the person who made the call, captures the reply, and answers the next person from memory.

The system I built

Four services, one fleet: a Next.js console, an Express API, a Node worker fleet and a Go memory service on ECS Fargate, rolled out health-checked with memory first. Under them sit 15,700+ automated tests with none skipped, 25,300+ counting Breken's, and 214 verification gates.

What it is made of

  • Memory agents. An extraction agent turns every source into typed facts through a validated tool schema. Consolidation, episode and relationship memory build on top, with an expertise map of who knows what.
  • A hybrid memory service in Go. TurboPuffer holds the vectors, Neo4j the graph and Postgres the canonical facts: 267k vectors, 60.5k graph nodes and 392k relationships in production. An append-only ledger records every mutation, and deletion proofs show a removed source is gone from every store.
  • Queues that lose nothing. Twelve Redis Streams work queues on consumer groups, stuck claims recovered with XAUTOCLAIM, tenant-fair scheduling, and ten dead-letter streams with triage and quarantine. A pool fix sized from that topology lifted worker throughput 2.4×.
  • Ingestion from seven sources. Signed webhooks and pollers normalise every item into one fingerprinted Postgres record, so a re-delivery never re-indexes.
  • Retrieval that resolves permissions before generation. The permission set is frozen before retrieval starts, and the model can narrow scope but never widen it. Every claim must be grounded in a source the asker may open, then pass an entailment check.
  • A tenant boundary in the database. Row-level security is forced on 103 tables, and the API and the worker refuse to start if one is not.
  • Observability as code. Sentry on all four services, Amazon Managed Prometheus, and 41 alert rules routed to PagerDuty and Slack, provisioned in Terraform.
Fig. 01One answer, split by clearanceA question asked in a public channel becomes two deliveries and one audit record.
  1. Asked in the channel

    Someone asks in Slack. Their permission set is frozen before retrieval starts, and the model can narrow it but never widen it.

  2. Permissions resolved per source

    Every candidate source is checked against what this person may open. Anything they cannot read never reaches the model.

  3. Answer assembled per source

    Each claim stays tied to the source it came from, grounded and checked before anything is shown.

  4. Split by clearance

    The cleared part posts in the channel with its sources. The restricted remainder goes to the asker by DM.

  5. Written to the ledger

    Every access decision lands in an append-only audit ledger.

Key decisions

Isolation lives in the database, not in the query. Row-level security is forced on 103 tables, so Postgres refuses another tenant's rows even when application code asks for them by mistake. The usual answer is a tenant filter on every read, which holds exactly until someone writes the one query that forgets it. Forcing it in the database made the invariant checkable: both services read the live catalogue at boot and refuse to start if a table is uncovered.

Split the answer; never downgrade it. Answering at the asker's full permissions puts restricted material in a public channel. Answering only from channel-safe sources silently drops the detail that mattered. Answering only in private teaches the channel nothing, so the question comes back next quarter. The split costs more: retrieval cannot flatten sources into one context, and generation has to track which claim came from which source. That tracking is what makes the answer safe to post.

Measure the hot path before scaling it. Two of the hottest graph queries were paying for scans. Purpose-built indexes cut one from 42,007 database hits to 20, a 2,100× drop, and the other by 303×, stable across eight runs. The whole index batch applies in 164 ms on a graph forty times production size.

The outcome

Brekfuz runs in production on AWS. The memory agents have handled 100,000+ requests, and every answer lands in the Slack thread it was asked in. Over fourteen days the load balancer served 213,761 production requests at a 7 ms p95 at the API front door. I also built Breken, Brekfuz's self-healing software: that story is next.