Framework- and Model-Agnostic by Design

Most platforms ask you to adopt their abstraction: their agent class, their orchestration loop, their plugin system. AgentCore Runtime makes a different bet. It hosts a container that speaks a known wire protocol — and it never looks inside to see which framework you used to build the thing answering requests.

This is the conceptual backbone of the whole platform. AWS states two foundational properties:

1. Framework-agnostic — Runtime hosts a container that speaks a known protocol, not a framework. The framework lives inside the container.
2. Model-agnostic — the model is just a config value inside your agent code (Bedrock, OpenAI, Gemini, Anthropic API, etc.); AgentCore never inspects it.

Concretely: you write an agent in any framework (or none), wrap it so it exposes a small standardized contract, package it as an ARM64 container (or a direct code zip), and hand it to AWS. AWS runs it serverlessly — each user session in its own dedicated microVM — and invokes it through the InvokeAgentRuntime data-plane API.

The contract is one of four protocols. Your runtime declares one protocol mode, and AWS routes the container port accordingly:

The point of the table is not to memorize ports — it is to see the architecture. AWS owns the outside of the box: the ports, the health checks, the session headers, the routing. You own the inside: whatever code answers on that port. As long as your container honors the contract, AWS does not care whether the answer came from Strands, LangGraph, a hand-rolled if statement, or a model you host yourself.

If the protocol is the contract, the @app.entrypoint decorator is the seam where AWS's managed HTTP server hands a request to your framework's agent object — and hands your reply back. It is the single most important line to understand in this lesson.

The Python SDK (package bedrock-agentcore) ships BedrockAgentCoreApp, a thin Starlette/Uvicorn ASGI wrapper. It turns a function into the full HTTP service contract: it wires /invocations, /ping, optionally /ws, the session headers, streaming, and async task tracking — all the protocol plumbing from the table above. It is framework-agnostic by construction; it does not know or care what runs inside your entrypoint.

Here is the minimal agent. Note the "four lines to deploy" — import, construct, decorate, run:

from bedrock_agentcore.runtime import BedrockAgentCoreApp
from strands import Agent

app = BedrockAgentCoreApp()      # 2. the managed HTTP server
agent = Agent()                  # your framework's agent object

@app.entrypoint                  # 3. the SEAM
def invoke(payload):
    result = agent(payload.get("prompt", "Hello"))
    return {"result": result.message}

if __name__ == "__main__":
    app.run()                    # 4. local http://localhost:8080; in container binds 0.0.0.0:8080

Read it from the boundary inward:

• Above the seam (AWS owns it): app = BedrockAgentCoreApp() and app.run(). A POST /invocations arrives, the SDK deserializes the body to payload, and routes GET /ping health checks on its own. You wrote none of that.
• At the seam: @app.entrypoint marks the one function AWS calls per request. The function signature is the interface: it receives the request payload and returns a JSON-serializable result.
• Below the seam (you own it): agent(payload.get("prompt", "Hello")). This body is the only part that changes between frameworks.

Because BedrockAgentCoreApp reproduces the exact cloud contract locally, you can test the wire protocol on your laptop before deploying:

curl -X POST http://localhost:8080/invocations \
  -H 'Content-Type: application/json' \
  -d '{"prompt":"What is the weather?"}'

For streaming, an async generator entrypoint auto-serves text/event-stream; each yield becomes one SSE data: event — same seam, different shape:

@app.entrypoint
async def handler(request: dict):
    agent = Agent()
    async for event in agent.stream_async(request.get("prompt", "")):
        yield event

Framework-agnostic is not marketing — it is a concrete, testable claim: only the body inside the entrypoint changes between frameworks. AWS names a specific set of supported frameworks, with Strands Agents first-class/recommended, plus LangGraph/LangChain, CrewAI, LlamaIndex, Google ADK, OpenAI Agents SDK, and your own custom code.

Each framework differs in exactly three places: how you build the agent object, how you call it inside the entrypoint, and how you pull the result out:

Line up the LangGraph version against the Strands version from the previous section and the invariant pops out: @app.entrypoint, payload.get("prompt"), returning {"result": ...}, app.run(), and the entire deploy flow are identical. Only the three highlighted columns move.

# LangGraph — same skeleton, different body
from bedrock_agentcore.runtime import BedrockAgentCoreApp
app = BedrockAgentCoreApp()
graph = builder.compile()                      # <- build differs

@app.entrypoint
def invoke(payload):
    out = graph.invoke({"messages": [("user", payload.get("prompt", ""))]})  # <- call differs
    return {"result": out["messages"][-1].content}                          # <- pull differs

if __name__ == "__main__":
    app.run()                                  # <- identical

A couple of per-framework notes worth carrying forward: OpenAI Agents SDK and Google ADK are async, so make the entrypoint async (or wrap the call in asyncio.run(...)). CrewAI's sample needs Python 3.11+ and defines agents/tasks in config/agents.yaml / config/tasks.yaml. The AWS samples repo keeps reference folders for all of these under 03-integrations/agentic-frameworks/ (including autogen, claude-agent, pydanticai-agents, and a TypeScript mastra sample).

The second backbone property is the mirror image of the first. Just as AgentCore never inspects your framework, it never inspects your model. The model is configured inside your agent code — AgentCore Runtime has no model field, no provider dropdown, no API surface that says "which LLM." It hosts a container; the container decides.

With Strands, a Bedrock model is one constructor:

from strands import Agent
from strands.models.bedrock import BedrockModel

model = BedrockModel(
    model_id="amazon.nova-pro-v1:0",   # or a Claude / cross-region inference profile
    region_name="us-east-1",
    temperature=0.3,
)
agent = Agent(model=model)

Bedrock model IDs can be a plain ID (amazon.nova-pro-v1:0) or a cross-region inference profile prefixed us. / global.. Switching to a non-Bedrock provider means swapping the provider class — nothing about the entrypoint, the container, or the deployment changes:

# Same agent, OpenAI instead of Bedrock — one line moves
from strands.models.openai import OpenAIModel
model = OpenAIModel(model_id="gpt-4o")   # API key injected at runtime, not baked in
agent = Agent(model=model)

Where do the credentials for a non-Bedrock provider come from? Not baked into the image. AgentCore Identity injects them at call time from a managed token vault using decorators like @requires_api_key(provider_name=..., into="api_key"); keys are stored in AWS Secrets Manager via CreateApiKeyCredentialProvider. (Deep dive comes in the Identity module — for now, just know secrets live outside the container.)

Decoupling the operational platform from the framework and the model buys you three things that compound in production.

1. Portability. Your agent is a container that honors a contract. The same artifact runs locally under app.run(), in CI behind the curl against /invocations, and in AWS behind InvokeAgentRuntime — without code changes at the seam. You are not locked into a vendor's agent abstraction; you are locked into a protocol, which is a far smaller, more portable commitment.

2. No rewrite to switch frameworks or models. This is the practical payoff of "same agent, six wrappers" and "model as config." Migrating from LangGraph to Strands touches the three columns inside the entrypoint, not the deployment. Swapping Claude for an OpenAI or Gemini model touches one provider line. Your session isolation, identity, memory, and observability wiring — the expensive parts — stay put. Compare this to classic, fully-managed Amazon Bedrock Agents, which ties you to Bedrock-hosted models and AWS's own orchestration loop. AgentCore is the modular, code-first, framework-agnostic alternative; the two coexist rather than one deprecating the other.

3. À-la-carte adoption. AgentCore services are modular and "work together or independently." You do not have to adopt the whole platform. You can run your agent on EKS, Lambda, or ECS and still use only Gateway (expose tools as MCP), only Code Interpreter (a managed sandbox), or only Memory (a managed store). Each service has its own SDK/API surface and is independently billable.

        Adopt the whole platform              ...or pick services à la carte
        ┌──────────────────────────┐         ┌──────────────────────────┐
        │  AgentCore Runtime        │         │  Your agent on EKS/Lambda │
        │   (your container)        │         │            │             │
        │  + Memory + Gateway       │         │   calls only ── Gateway   │
        │  + Identity + Observ.     │         │   calls only ── Memory    │
        └──────────────────────────┘         └──────────────────────────┘

The through-line: by standardizing the boundary (a protocol contract + the @app.entrypoint seam) instead of the implementation (a framework or a model), AgentCore lets your agent logic stay yours while AWS handles the operational heavy lifting — and lets you change your mind about frameworks, models, and which services to use, without a migration project.