Personal AI tools make individuals faster. AlphaAgent makes the firm capable of something new: today we are launching AlphaAgent Organisations and AlphaAgent Studio V2.
Since we launched the original AlphaAgent on 1 July 2026, we have spoken to dozens of capital markets and banking firms about their AI strategy, and the best of them are thoughtful about it. Their people use Claude, Claude Code and ChatGPT every day. Their technology teams are building on Amazon Bedrock, Google Vertex AI and the model APIs to make business processes agentic.
Both are the right instincts, and each leaves a gap. Personal tools are as easy as it gets, but the work lives with one person in one chat window, and it cannot be repeated, shared, versioned or governed. Building at the API level gives you every control, but every agent starts as an expensive and time consuming engineering project: the orchestration, grounding, approvals, audit and deployment are yours to build, long before the hardest problems in the firm can be handed over with confidence.
So the question we kept coming back to was this. Is there a solution with the flexibility and ease of use of a consumer-grade product, and the security, governance and flexibility of building on enterprise cloud services? We think there is. It is AlphaAgent.
Beyond personal AI tools
AlphaAgent is an operating system for agents that mirrors how a high-performing team works: specialists grounded in your doctrines and policies, running at scale and privately. Everything runs inside your firm’s own AWS, under your own security controls and on your existing AWS agreement. Your data and your agents never leave it, and we never have access to them. The only thing that reaches us is a licence heartbeat and a token count.
It starts just as flexibly as a personal tool. An analyst opens Studio, asks a question in plain language, connects the systems the firm already runs, and watches an agent plan and do the work. Nothing to build first.
What is different is what happens next. AlphaAgent enforces the practices that autonomous, agentic systems need before they can be trusted with complex work: every resource versioned, every step overseen, approvals held by people, every action attributed, and a firm’s own knowledge for agents to be grounded in. Flexible to start, disciplined by design.
Studio is where people do the work. Organisations is where the firm governs it. AlphaAgent Libraries connect the two. The key concepts page draws the whole system in one picture.
Everything is versioned
One principle runs through all of it: every resource is versioned. Agents, workflows, data connectors and knowledge graphs each keep immutable versions. An agent pins to the connector and knowledge graph versions it was configured with and keeps them until someone moves it, so what runs is always a known, recorded version and a change happens only when someone chooses it. Nothing in a chat window is versioned.
Where the work starts: Studio
An analyst builds a specialist agent in Studio. Studio drafts the system prompt from the analyst’s description and the analyst reviews it; every edit after that is a new version of the agent.
The agent can be grounded in the firm’s doctrines and policies through our multi-resolution knowledge graphs, built from the firm’s own documents. Each build is a version, and each agent pins to the version it should answer from, so answers cite the firm’s own sources rather than a model’s general recall.
The Governor oversees every step. At regular checkpoints the agent justifies its next action and the Governor rules on it. When the agent drifts from its objective, the Governor steers it back, and when the agent needs its sources, the Governor sends it back to its knowledge graph. It is on for every agent with nothing to enable, and everything it said is on the step’s card for the analyst to read.
Data connectors reach the systems the firm already runs: PostgreSQL and MySQL, Snowflake, any REST API described by OpenAPI, MCP servers and AWS resources via boto3. Studio drafts a connector’s guide from the system’s own schema or specification where one exists, and credentials stay in the deployment’s own secret store and never enter a prompt.
Agents run their code in sandboxed execution environments, with network access only through the connectors the firm attaches. That is what lets work run on a schedule while nobody is signed in, and leave every action on the record.
Once the analyst cracks a problem, they simply ask for that exploration to become a structured workflow. The agent builds it from the plan it just ran. The analyst reviews each step, turns on approval where sign-off matters, saves it as a version, and sets it to run on a schedule.
Exploration becomes a repeatable process in a single request.
How it spreads: AlphaAgent Libraries
A prompt in a personal tool lives in one person’s history. A Library carries a versioned workflow, with everything it depends on, to every team with access.
The analyst shares their work to AlphaAgent Libraries, the firm’s internal store for agents, workflows, knowledge graphs, data connectors and execution environments, and chooses which version to share. Think of it as an internal app store with governance built in. An administrator creates each Library and adds people or Entra ID groups as Contributors, who publish and pull, or Readers, who pull.
A workflow travels with everything it depends on: its agents, connectors, environments and knowledge graphs. It lands in a colleague’s Studio wired to those copies, as a draft ready to activate.
Every copy records where it came from, down to the source version. When the source improves, colleagues choose Update my copy and take the new version. Connector credentials move directly between the firm’s own deployments and are never stored in the Organisation. Every share and pull is on the record.
If your teams already use Claude, their skills, memories and MCP servers come with them. Nothing they have built is wasted.
Into production: Governed Studio deployments and the AlphaAgent API
A personal tool cannot be called by your systems. A governed deployment can, with a person still signing off.
When a team adopts the work, it pulls it into a governed deployment. Everyone assigned works on the same agents, workflows and knowledge graphs, with one active version of each for the whole deployment, so the workflow version an administrator activates is the one everyone’s runs and schedules use. Every change and every run is attributed to a person or an API key.
Personal data is masked by default. A workflow can tighten PII redaction, but it can never loosen it.
Workflows in a governed deployment can now be triggered by the firm’s own systems through a REST API. A system starts a run, follows it step by step and collects its outputs, with a key an administrator issues for that deployment and those workflows alone.
Autonomous does not mean unsupervised. A step that needs sign-off waits in Studio’s Inbox, marked as raised by an API run and visible to everyone assigned. The API can see it, but only a person can release it, and whoever does is recorded on the run.
One view for leadership: Organisations
Personal tools have no fleet. Here one console sees every deployment and keeps them on a chosen release.
Personal tools have no fleet. Here one console sees every deployment and keeps them on a chosen release.
Organisations is installed once. One console shows every Studio deployment across the firm, who can sign in through Entra ID, what each role can do, every Library and every API key. Each team’s deployment is isolated from every other, with its own limits and its own bill.
Versioning reaches the fleet too. A Fleet Configuration Template is a versioned set of deployment settings that names a release, and Update Manager rules keep the deployments you list on that release, inside a maintenance window. A rule keeps applying the template version it was pinned to until an administrator adopts the new one. Every update takes a restore point first, and any failure is visible and recoverable from the console. The audit log records every role grant, API key change and deployment update.
Metering receipts carry token counts and who caused them, never content, and security teams can read exactly what leaves your environment.
What this means for the firm
That changes what agents can take on. Where AI bolted onto a process stays at human scale, AlphaAgent lets the firm rebuild the process around what agents can do: from validating a day’s extracts, to answering a margin query cited to the ledger, to closing a country’s month end with journals proposed and explained.
Flexible to start, disciplined by design. Processes reimagined agent-first, by the people who know them best.
Availability
AlphaAgent Organisations and AlphaAgent Studio V2 are available today through a private offer on AWS Marketplace.
Documentation
Everything above is documented in full at docs.alphaagent.prometheusrl.com, with every page written to be read by a person or by your own agent.
| Start here: What is AlphaAgent | https://docs.alphaagent.prometheusrl.com/ |
| Key concepts | https://docs.alphaagent.prometheusrl.com/introduction/key-concepts |
| Install: cloud engineers begin at Before you start | https://docs.alphaagent.prometheusrl.com/installation/before-you-start |
| Deploy your first Studio | https://docs.alphaagent.prometheusrl.com/installation/deploy-your-first-studio |
| Studio guide | https://docs.alphaagent.prometheusrl.com/studio-guide/agents |
| Programmatic access: Overview | https://docs.alphaagent.prometheusrl.com/programmatic-access/overview |
| Organisations guide: Fleet | https://docs.alphaagent.prometheusrl.com/organisations-guide/fleet |
| Security and architecture: Architecture overview | https://docs.alphaagent.prometheusrl.com/platform-internals/architecture-overview |
| Connect your own agent | https://docs.alphaagent.prometheusrl.com/introduction/connect-your-agent |
