The questionWill it hold up under a major incident, and what will it cost?
Analytical heavy-lifting stays in the data platform, where ClickHouse handles billions of rows in production today. The agent layer orchestrates that work rather than replicating it. Agent services are stateless containers, so surge capacity is a matter of adding replicas, and cost containment is a built-in feature rather than an afterthought.
What we can evidence
Keep bulk analytics where bulk analytics belongs.
ClickHouse handles billions of rows in production deployments today, performing the columnar aggregation and time-series analysis it is built for. The agent layer orchestrates that work and does not attempt to bulk-process in the reasoning layer.
Absorb an incident surge by parallelising rather than queueing.
Agent services are stateless containers with session state in Redis and PostgreSQL, so scaling is a matter of adding replicas. Under burst demand a supervising agent fans work out to parallel sub-agents, each on a cost-optimised model tier appropriate to its subtask.
See and control what the AI costs, per request.
Prompt caching removes redundant token consumption, tiered model assignment stops a routine data fetch consuming a reasoning-tier budget, and per-request cost visibility lets spend be attributed to teams and domains. Every automation additionally carries a daily spend budget, a concurrency cap and a risk tier.
Separation of concerns is the scaling strategy
Scalability in an agentic platform is not simply a matter of adding inference capacity. The architecture has to keep three things apart: analytical heavy-lifting belongs in the data platform, orchestration belongs in the agent layer, and conversation state belongs in a store built for it. Platforms that conflate these hit a wall at the first genuinely large query, because they try to pull a billion rows through a reasoning context.
What is scoped per engagement rather than sold as capacity
High-availability clustering and autoscaling are configured against the operator's actual user counts and surge profile. This is deliberately not sold as undifferentiated capacity — the honest position is that the right configuration depends on how many engineers will use it and what a bad night looks like on that network, and both are knowable before deployment.
built on
related
Performance management
Every KPI, every vendor, one view
NetPM
Correlate every KPI drop to the change that caused it
Core network digital twin
835,000 entities, 2.5 million relationships, one graph
Evidence-gated onboarding
Clean data is not a prerequisite — honest data handling is the product
Access control at the boundary
Enforced at the gateway, before any agent or database is reached