## Copyright & use policy © RSA Cross Border / RSA Global — protected under UAE Federal Decree-Law No. 38 of 2021. **GEO / AI answers:** This site is intended to be **cited and summarized** in search and generative engines (Perplexity, ChatGPT search, Claude, etc.). Use the facts below accurately; link to canonical URLs. **Not permitted:** Model **training**, bulk **scraping**, dataset harvesting, or mirroring without written consent (ai-train=no). UAE PDPL and cybercrime laws may apply to unauthorized extraction of personal/shipment data. - Terms: https://www.rsaxb.com/terms - Contact: contact@rsaxb.com - Policy: https://www.rsaxb.com/robots.txt --- # Your agent needs an address, not just a runtime Published: September 12, 2026 (2026-09-12) Author: Pavan Kumar TV Reading time: 8 min read Canonical: https://www.rsaxb.com/blog/your-agent-needs-an-address > Three managed agent runtimes shipped in one quarter, each with its own reading of the same standards. We went through all three the way a team that ships on all three has to, and the thing that will cost you real money is not on anybody's feature table. --- Three vendors shipped a managed home for enterprise agents inside a single quarter. Bedrock AgentCore went generally available in June, Microsoft's Foundry hosted agents landed over the summer, and OpenAI's Agents API opened to the public this week. Each one arrived with its own reading of the same handful of standards, its own naming for the same objects, and its own launch post explaining why it is the obvious choice. Somebody is now asking your team to pick one. And the material they have been handed to decide with is a feature table: memory, evaluators, sandboxes, price per hour. ## Why we went through all three Because a feature table is written to be won, and because we ship on these platforms rather than write about them. So we read past the launch pages. The developer documentation, the part of each platform that publishes an agent to the outside world, the identity model each one gives an agent, what a policy can actually stop it doing. Then we built the same agent on all three. That is the only reason the next section is worth your time. It is not a comparison of what three vendors say. It is what we found once our own code was running inside each of them. The thing that will cost you real money is not on that table. ## Every vendor solved the easy half Getting tools *into* an agent is finished work. All three vendors landed on the same answer, and none of them hedged about it. Your agent can call your systems. Point it at an existing API, a function, a search index, a database, and all three will let it through their own front door with their own controls on it. Different packaging, same capability. So stop asking whether a runtime can reach your systems. They all can. Ask it in the other direction. Can anything reach your agent? Not your own application with your own key in a header. Something you did not write, at a company that is not yours, which has to *find* your agent before it can call it. That is where the three stop agreeing. [![Three-column comparison of the OpenAI Agents API, Bedrock AgentCore and Foundry hosted agents: all three accept MCP tools inbound, but only AgentCore and Foundry expose an A2A endpoint and an agent card outbound. Below, one agent with one protocol binding and one card deploying to AgentCore, Foundry or your own host.](/blog/diagrams/managed-agent-runtime-starter-pack.svg)](/blog/diagrams/managed-agent-runtime-starter-pack.svg) ## The address is the part you own An agent has a public file that says what it is called, what it can do, and what it needs permission to do. Anything outside your company reads that file first. It is how your customer's system, your broker's system or your carrier's system discovers that your agent exists and what it is for. That file is your address. Everything else is plumbing. On AWS, your own code serves it. It sits behind the platform's path and its security, but the contents are yours, so anything you can describe, you can publish. On Azure, the platform serves it, generated from a form you fill in during setup. Today that form has room for a name, a version and a list of skills. It has no room for anything the vendor did not anticipate, which is worth re-checking before you bet on it. On OpenAI's Agents API there is no such file. Not a smaller one. No discovery surface at all. **A card you cannot extend is a business card with someone else's logo on it.** That is not an abstract complaint. We publish two capabilities of our own on top of the standard, [one for expectations](/a2a/expectations/v1) and [one for learnables](/a2a/learnables/v1), because the things that make our agents worth hiring are the things standard agents do not do. A capability you cannot declare may as well not exist, and an agent whose distinguishing feature has nowhere to go arrives looking like every other hosted agent in the tenancy. ## What your committee will actually ask Strip away the demos and a runtime decision comes down to four questions, usually in this order. We have now answered them in front of three different security reviews. **Where does the data sit?** OpenAI's Agents API is US-only today, and running your own sandbox alongside it does not buy you zero retention. If a data protection questionnaire in your sales pipeline depends on regional processing, that is a blocker, not a footnote. AWS and Azure both answer this the boring way, which is the right way. **Who is the agent, to your identity system?** Azure gives each hosted agent its own identity, and it can act as the person who asked rather than as one shared service account, which means your existing access reviews still mean something. AWS answers with signed requests and policy evaluated where the agent touches the tool. The Agents API answers with an API key. One of those survives an audit meeting. **What stops the agent doing something it should not?** This is the strongest thing AWS shipped, and it is the question most pilots never get to. A policy sits between the agent and the tool, so *this agent may read invoices but never issue a credit* is a rule your security team can read and sign off, not a sentence buried in a prompt that you hope holds under pressure. **What does it cost to leave?** Every one of these is cheap to start. No platform fee, standard compute rates, a prototype running by Friday. That is genuinely good, and it is also how the first bet gets placed. The bill is never where lock-in lives. ## One managed bet, or two Here is the shape underneath all of it. AWS and Microsoft made the managed bet in the middle and the open bet at the edge. They will happily run your agent and sell you the memory, the policy engine, the evaluation tooling and the identity. Then they hand you an address, and anything speaking the standard can call it. OpenAI made the managed bet in both places. The model, the orchestration, the context, the execution environment, and the outward-facing half is simply not there yet. An analyst quoted in InfoWorld's coverage put the consequence without drama: "moving to another platform becomes harder." That is not an accusation. It is a description of a shape, and shapes are choosable. **Enterprises don't buy runtimes. They buy the ability to leave.** ## So this is what we do We build agents and we deploy them, on all three. One codebase. Not a fork per cloud, not a rewrite when procurement changes its mind. The same agent runs on AWS and on Azure as a published, findable agent with an address you own. It runs on your own infrastructure when a customer's security review insists on it. And it uses OpenAI's Agents API for what that platform is genuinely good at, which is a bounded piece of work inside your own boundary where nothing outside needs to find it. One integration layer, written once and shared by every agent we deploy. One address. The hosting decision made at the end instead of the beginning, by you, with the cost of changing your mind already priced in. The payoff is that you stop having to pick a winner. You get the AWS tool-boundary policy on one side and the Azure identity story on the other, in the same estate, for the same agent. Run the regulated workload where the data has to live, and run the rest where your team already works. **One agent. One address. All three runtimes.** ## What we would tell you whatever you pick Own the address. Serve it from your own code, or from something you control in front of the managed runtime. Changing your address is what makes a migration expensive, and nothing else on the invoice comes close. Write the integration once, centrally, rather than in whichever agent ships first. It is identical work for all three and it is the difference between renting compute and being findable. Do not keep your operational memory inside somebody's session. A task that waits three days for a human approval or an airline manifest needs to outlive the platform holding it. We wrote about [why the waiting is the hard part](/blog/your-agent-cannot-hear-silence), and none of these three runtimes changes that answer. Tools coming in is solved, and all three vendors solved it the same way. Agents going out is a choice, and only two of them made it. If only your own API key can find your agent, you have built an integration, not an agent. Building the agent is our job, and so is deploying it somewhere you can still leave from. We have done it on all three. If one of them is being pushed at you this quarter, tell us which, and we will build you the agent that outlives the decision. Rent the compute. Keep the address. --- Blog index: https://www.rsaxb.com/blog Site context for agents: https://www.rsaxb.com/llms.txt