Loading today’s stories
Build1 distinct publisher3 min readUpdated
AWS published the build pattern most agent demos skip: isolation and cost attribution scoped per customer, not per application. Axonius chose silo and kept its existing tenant plumbing.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
AWS has published an account of how Axonius, an asset intelligence platform for security and IT teams, deployed AI agents across a multi-tenant SaaS estate on Amazon Bedrock AgentCore [s1a][1]. The interesting part is not the agent. It is that the write-up treats tenant isolation and per-tenant cost tracking as first-order architectural requirements, which is the dimension a single-tenant agent design never has to answer [2].
The framing in the post is the standard SaaS trio applied to agents: silo, bridge, and pool [3]. Silo means dedicated resources per tenant, which on AgentCore runtime translates to a dedicated agent per tenant [4]. Pool means one agent serving many tenants, with each user session isolated by a unique session ID [5]. Bridge mixes the two, for example a dedicated runtime agent sitting on shared Amazon Bedrock Knowledge Bases, AWS's managed retrieval augmented generation service [6].
Axonius already runs silo. According to the post, each customer workload sits in its own Amazon VPC containing an Application Load Balancer, a Network Load Balancer, databases and general compute, across hundreds of isolated customer environments on AWS [7][8]. The company chose to keep that model rather than reshape tenancy around the new workload [9]. That decision has arithmetic attached: one dedicated agent per tenant across hundreds of environments means hundreds of agents to deploy, patch and watch [10], which is why the post lists fleet-scale observability with alarms as an explicit requirement from the DevOps team [11].
The agent itself interprets the state of large enterprise environments and identifies gaps and risks, analysing millions of data points from dozens of concurrent integration sources, with the stated aim of letting junior analysts run complex analyses without consuming senior analyst hours [12]. Axonius reconciles data from over 1,400 systems, and says it reduces the manual burden of security, audit and compliance work by up to 50 percent [13][14]. Those are vendor figures.
The requirement list is the part worth copying. Isolation: an agent serving one customer must be scoped exclusively to that customer's data [15]. Identity: the existing authentication and authorisation module lives on the tenant's EC2 instance, and the agent's identity flow had to integrate with it without disruption [16]. Integration: the tenant's agent needs secure access to that tenant workload's APIs [17]. Lifecycle: the agentic workload had to join the existing silo continuous delivery workflow [18]. And cost: the post states plainly that agentic costs can spiral, that most of the cost is model invocation, and that tracking model cost per tenant is what makes pricing an agentic offering possible at all [19][20].
That last item is the one single-tenant reference architectures quietly omit. If you cannot attribute model spend to a customer, you cannot price the feature, cap an abusive workload, or tell a renewal conversation from a margin leak. Silo gives you that attribution close to free, at the cost of fleet management; pool gives you density and pushes the accounting problem into session-level metering [4][5].
What to watch: whether ISVs on the pool side get per-session cost attribution that is good enough to bill against, and how many silo adopters find that hundreds of independently deployed agents outgrow their CD and alarming setup before the isolation benefit pays for itself. The published Axonius requirements are a usable checklist for that comparison [2].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
ISVs choosing an architecture have three common patterns: silo, bridge and pool.
The silo model gives tenants dedicated resources, which for AgentCore runtime means using a dedicated agent per tenant.
In the pool model tenants share resources and one agent serves multiple tenants; with AgentCore runtime each user session can be isolated by allocating a unique session ID per session.
The bridge model has some components in silo mode and others in pool mode, for example a dedicated agent deployed into AgentCore runtime using shared Amazon Bedrock Knowledge Bases, an AWS managed Retrieval Augmented Generation service.
Axonius reconciles data from over 1,400 systems into one authoritative source of truth.
Axonius states it reduces the manual burden of security, audit and compliance by up to 50 percent.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Single vendor-authored account, detailed but unverified
Everything rests on one AWS blog post co-authored with the customer. The architectural mechanics are specific and internally consistent, which is worth something, but there is no independent source, no measurement, no benchmark and no third-party confirmation, and the supplied body is truncated before the chosen architecture is fully described.
One named ISV deployment, scale undisclosed
There is a concrete, named adopter putting its first agent on AgentCore in silo mode, which is more than an announcement, but the disclosure stops there: no number of live agent runtimes, no rollout stage, no other adopters, and no usage or cost telemetry.
Mostly sober engineering write-up with vendor gloss
The bulk of the post is restrained requirement-and-pattern description rather than capability boosterism, so the gap is small. It tips mildly positive because product framing figures such as the up-to-50-percent manual burden reduction are asserted without methodology and are unrelated to the agent, and because a fleet-scale silo pattern is presented without any operating or cost numbers to show it works at that scale.
Vendor blog promoting its own agent platform with a customer
The sole source is AWS's own blog describing an architecture built on AWS services, naming AgentCore, Bedrock Knowledge Bases, Cognito, VPC and EC2 throughout, with a partner whose product claims are also promoted. Both parties gain from the account reading well, and no alternative or non-AWS option is evaluated.
Moderate on the pattern, weak on outcomes
Confidence is reasonable that the described requirements and the silo choice are as stated, since the account is first-party and specific. It is low that the pattern is proven at hundreds-of-tenant scale or that cost attribution works as intended, because there is one source, no independent verification, no metrics, and the supplied text is cut off before the chosen architecture is fully laid out.
build
AWS moves agent authorization out of the agent and into the plumbing1 distinct publisher
build
AWS moves agent source-vetting into the API call with per-request web search filters1 distinct publisher
build
AWS puts a number on agent displacement: IaC authoring from 3-4 weeks to minutes1 distinct publisher
build
Agent payments stop being a demo when the wallet lives outside the model's reach1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 18, 2026