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, chat, connector, workflow, knowledge-base, code-execution, and notification capabilities |
| 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} | Per-session working 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 or external) | 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 in either mode. Self-hosted runs single-node Neo4j Community as a Fargate service inside the Studio VPC, backed by encrypted multi-AZ EFS, and Studio reaches it internally at bolt://neo4j:7687. External points Studio at your own Neo4j over the network. AWS 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).
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 AWS 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 AWS Bedrock inside your residency zone — there are no calls to any third-party model API.
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.