What runs in your account
AlphaAgent Studio is not a hosted service — it runs as a set of resources inside your own AWS account, and almost everything it does happens there. This page is the technical evaluator's map of those resources, how an agent run actually executes against the models, and what "Express" and "Deep Traversal" mean at a behavioral level. It is the foundation for the residency, sandboxing, and telemetry details in the rest of this section.
The single trust boundary
There is exactly one boundary that matters: your AWS account. Studio's web app, its services, your agent definitions, your conversations, your connector credentials, your workspaces and datasets, and your knowledge graphs all live inside it. The only traffic that ever leaves that boundary is the signed license and usage channel back to the AlphaAgent Console — covered in detail in Licensing and telemetry. The Console never reaches into your account and holds no credentials to it.
The resources AlphaAgent provisions and uses
When you deploy Studio (see Overview and architecture), it creates and then uses a standard set of AWS resources in your account:
| Resource | What it is | What it holds or does |
|---|---|---|
| VPC with private subnets | A network boundary | All Studio compute runs inside it; outbound access is controlled |
| Application Load Balancer (ALB) | The single HTTPS entry point | Every request is authenticated at the load balancer before it reaches any service |
| Cognito user pool | Sign-in directory | Federated to your own identity provider over SAML; there is no self-signup |
| Studio application services (ECS Fargate) | The running product | The agent-runtime, chat, data-connector, workflow, knowledge-base, knowledge-base-mcp, code-interpreter (which hosts the spec-driven coder that runs analysis — see How agents run code), web search and browsing, and notification capabilities. Provisioned in five sizing tiers (xs, small, standard, large, xlarge); see Infrastructure costs and sizing |
| Per-environment code-execution Lambdas | alphaagent-env-{environment_id} functions | Where agent code actually runs, one function per execution environment |
| S3 workspaces bucket | alphaagent-workspaces-{account}-{region} | The conversation filesystem — specs, datasets, charts, fetched documents, reports, and scratch files produced when agents run code |
| Other S3 buckets | Uploads, results, and overflow storage | Document uploads, large workflow results, oversized message payloads |
| DynamoDB tables | The operational data stores | Agent and swarm definitions, conversations, runs, connector definitions, and the session-datasets table (see Datasets and data flow) |
| ElastiCache (Redis) | A cache | Speeds up configuration and conversation reads; not a system of record |
| Secrets Manager | The credential store | Connector credentials, service configuration, and the license secret |
| Neo4j (self-hosted) | A graph database in your account | Stores the knowledge graphs built from your documents (see Knowledge graphs in depth) |
| Amazon Bedrock | The model service | Runs all AI inference, pinned to your residency zone |
Neo4j stays in your account. Studio runs single-node Neo4j Community as a Fargate service inside the Studio VPC, backed by encrypted multi-AZ EFS, and reaches it internally at bolt://neo4j:7687. Amazon Bedrock is a managed AWS service that you enable model access for in your own account; Studio calls it but never routes inference outside your residency zone (see Data residency and security).
Web search and browsing also run as a Studio service inside your account: when an agent searches the web or opens a page, the outbound request originates from your own AWS account, not from Prometheus Research Labs. Only the public web content the agent asked for comes back; your data is not sent anywhere as part of this.
How an agent run executes against Bedrock
When a user sends a message to an agent, Studio resolves the agent's active configuration (its instructions, the data connectors it may use, the knowledge graph it is bound to, and the execution environment for code), then runs the agent against Amazon Bedrock and streams the result back to the chat in real time.
The run is durable. Studio records each run and its event stream in DynamoDB so that a browser which disconnects mid-run can reconnect and replay what it missed, and so a long-running background run keeps going even after the user navigates away. Inference itself always goes to Amazon Bedrock inside your residency zone — there are no calls to any third-party model API.
Runs are also built to stay stable over long durations. A deep traversal or a multi-node workflow can run for hours: the agent keeps its working context bounded automatically, large code-interpreter outputs are persisted to the workspace and referenced rather than dumped into the conversation, and the data it produces along the way (datasets and workspace files) stays available for the whole run rather than expiring partway through. You can always stop a run yourself if you want to end it early.
When an agent needs to compute, it does not write code inline. The orchestrating agent (run on Bedrock as a Sonnet "runner") emits a compact analysis spec, and a dedicated coder in the code-interpreter service fulfils it — running the code in your environment Lambda, reading documents, fetching connector data, and registering datasets and citations. In Deep Traversal, planning is handled by an Opus "planner". This is detailed in How agents run code.
Express vs Deep Traversal
Studio offers two execution modes for a chat turn. The difference is behavioral — how much planning happens before the agent answers — not where anything runs. Both run entirely in your account against Bedrock.
| Express | Deep Traversal | |
|---|---|---|
| Behavior | The agent answers directly, streaming as it goes | The agent first produces a plan, then executes it as a multi-step graph |
| Knowledge graph | Not used | Used, and consulted first |
| Approval | None — the answer streams immediately | The plan is shown to the user and execution resumes only after the user approves it |
| Best for | Quick questions and direct tasks | Complex, multi-part research where you want to review the approach first |
Express is the fast path: the agent goes straight to work. Deep Traversal is the deliberate path: the agent plans, pauses for your approval, then carries the plan out step by step, drawing on your knowledge graph. The user-facing experience of both modes is described in the Chat guide.
Where to go next
- Data residency and security — what stays in your account and what (narrowly) leaves it.
- How agents run code — the sandboxed code interpreter in detail.
- Overview and architecture — the deployment view of these same resources.