STACK REFERENCE
What we build on, and why.
Published because the choice of stack is a real question during procurement, and vague answers waste everybody's week. Everything named here we have run in production ourselves.
PRINCIPLES
Three rules behind every choice.
Boring where it counts
Postgres, queues, and typed contracts underneath. Novelty stays at the agent layer.
Portable by default
No single-vendor lock at the orchestration or model layer. Routing is ours, not theirs.
Observable from commit one
Tracing, evaluation, and cost attribution are scaffolding, not a later milestone.
THE STACK
Layer by layer.
Read each tag as an example, not a dependency. What matters is the layer; the specific product is chosen per engagement and can be the one you already own.
Tooling-agnostic by design.
Named tools are hardened examples of what we have already run in production, not the only systems we support. We select per-engagement, typically the tools you already own.
Agent frameworks & orchestration
Models & routing
Data & identity
Evaluation & observability
Commerce & community surfaces
Delivery & runtime
NEXT STEP
Want the architecture behind a specific outcome?
We'll walk the graph, the data contracts, and the evaluation plan on a call.