Convex
A reactive backend that syncs state between clients and server in real-time. Functions run server-side, data updates push to all subscribers automatically, and the type system spans the full stack.
- Convex Backend (Open Source)
- Nextjs
- Clerk
- AI Town
Reactive Backend Checklist
Ten rules for any reactive backend where functions run server-side and data syncs to clients automatically.
| # | Rule | Why |
|---|---|---|
| 1 | Keep the dev sync loop running | Types, schema, and backend code stay current. Stale codegen breaks everything downstream. |
| 2 | Commit generated code | Frontend and non-backend work type-checks immediately. Generated files are source, not artifacts. |
| 3 | Thin wrappers, fat helpers | API functions validate and delegate. Domain logic lives in plain TypeScript helpers. Testable without the framework. |
| 4 | Validate every public input | Public functions accept untrusted data. Argument validators are the contract. No validation = no contract. |
| 5 | Authorize every public function | Use server-verified identity, not user-supplied fields. Access control is not optional on any public endpoint. |
| 6 | Index real queries | Avoid broad filters on large collections. Index the access patterns you actually use. Review for redundant indexes. |
| 7 | Bound all reads | No unbounded collection scans. Paginate, denormalize, or constrain result sets. Context windows and APIs both have limits. |
| 8 | Internal functions for orchestration | Scheduled jobs, crons, and inter-function calls use internal-only functions. Never expose orchestration plumbing as public API. |
| 9 | Await everything | Every promise — scheduler calls, DB writes, async operations. Floating promises cause silent failures that compound. |
| 10 | Deploy deliberately | Dev is continuous sync. Production is an explicit promotion step. Inspect data and function health before promoting. |
Release Gate
Before deploying to production:
- All public functions have validators and access control
- All scheduled and internal calls target internal functions
- No unbounded reads remain on large data paths
- Redundant indexes reviewed
- No floating promises
- Generated code is current and committed
- Dashboard inspected — function health, data size, error rates
- Production deploy is a conscious decision, not an accident
Agent Comms Pattern
For multi-agent coordination on a reactive backend:
| Concept | What | Why |
|---|---|---|
| Thread | Persistent conversation scoped to a project | Memory — agents see full history automatically |
| Agent | Named role with instructions and tools | Identity — sharp roles prevent mush |
| Scheduler | Server-side turn engine | Orchestration — no polling, no manual relay |
| Subscription | Real-time UI updates via WebSocket | Visibility — humans see coordination as it happens |
The thread is the source of truth. Each agent continues the thread and sees what every other agent said. The scheduler handles turn management. The UI subscribes to the thread for real-time updates.
Guardrails: Max turns per conversation. Explicit stop conditions. Sharp role separation — "critic only outputs objections" not "helpful assistant." Session start/end events on threads for visibility.
Guides
Context
- Data Decision Software
- Agent CLI Tools — Agent-grade CLI checklist (the other side of the same system)
- Agent Protocols — How agents coordinate across boundaries
Questions
When your reactive backend syncs state automatically, where does the boundary sit between "the system handles it" and "the agent must handle it"?
- If generated code is source, what happens when two agents modify the schema simultaneously?
- How do you test multi-agent thread conversations without running the full backend?
- What's the minimum viable thread structure that gives session visibility without over-engineering?