GraphN vs Amazon Bedrock AgentCore and Strands Agents: integrated product or composable AWS services?
- Published
- August 5, 2026
- Reading time
- 11 min
Decision summary
Choose Strands Agents plus AgentCore when
AWS is the infrastructure standard, IAM and CloudWatch should govern agents, and AgentCore's separable runtime, memory, gateway, identity, tools, and policy services fit the architecture.
Choose GraphN when
builders need one visual and YAML workflow with a shared resource catalog, managed model serving and custom weights are central, or the team wants to avoid assembling an agent application from multiple cloud services.
Strands Agents supplies model-driven agents and Graph, Swarm, and Workflow patterns. Amazon Bedrock AgentCore supplies managed Runtime, Memory, Gateway, Identity, tools, and Observability that work with Strands or other frameworks. GraphN supplies one workspace for visual/YAML workflows, models, functions, MCP servers, knowledge, storage, secrets, and executions.
Amazon's agent stack is intentionally composable. A team can use Strands without AgentCore, AgentCore with LangGraph or CrewAI, and models inside or outside Bedrock. GraphN is intentionally integrated: its authoring, resource, execution, and inference layers are designed as one platform.
That makes this a comparison of operating models more than SDK syntax.
Note: This is a documentation-based architecture comparison, not a security certification, cost analysis, or performance benchmark. AgentCore services, supported regions, quotas, and framework integrations can evolve independently.
The complete boundary
Scroll horizontally to compare
| Layer | Strands + AgentCore | GraphN |
|---|---|---|
| Authoring | Python/TypeScript Strands code; Graph, Swarm, and Workflow patterns | Canvas and versioned YAML DSL |
| Runtime | AgentCore Runtime, or another compute platform | Managed GraphN workflow execution |
| State | Strands SessionManager; AgentCore Memory options | Execution state and versioned resource snapshots |
| Tools | Python/TypeScript tools, MCP; AgentCore Gateway and built-in tools | MCP servers, connectors, isolated functions |
| Identity | IAM plus AgentCore Identity and external IdP integration | Workspace membership, API keys, secrets |
| Models | Bedrock and many external providers | Built-in open models, external endpoints, custom weights |
| Telemetry | OpenTelemetry and CloudWatch/AgentCore views | Integrated execution traces, logs, and usage |
| Deployment unit | Agent application/runtime resource | Published workflow and linked resources |
AgentCore is not limited to Strands. Its overview lists LangGraph, CrewAI, LlamaIndex, Google ADK, OpenAI Agents SDK, custom frameworks, and models in or outside Bedrock. Strands is the AWS-origin framework with the most direct built-in integration, not a required control plane.
Strands orchestration versus GraphN workflows
Strands multi-agent patterns distinguish:
- Graph: explicit nodes and edges for controlled execution;
- Swarm: collaborative agent handoffs with more emergent routing;
- Workflow: an application pattern that chains tasks, with a Python tool available for dependencies and parallel execution.
Graph and Swarm can share invocation state across agents. Strands code can also define normal tools, callbacks, and model providers, so orchestration remains part of an application repository.
GraphN supports explicit steps plus higher-level multi-agent forms such as parallel analysis, handoff routing, and judge loops. The workflow is a versioned platform resource shared by the visual editor and YAML tooling.
The abstraction choice should follow who changes the workflow:
- Strands fits a software team that wants orchestration reviewed and deployed as application code.
- GraphN fits a mixed team that needs to edit and inspect the same workflow through UI, YAML, CLI, and API.
Session state and memory
Strands session management can persist agent messages, state, and multi-agent execution snapshots. For Graph or Swarm, the orchestrator owns the session manager; child agents must not attach their own conflicting managers. Multi-agent sessions restore orchestrator state but do not automatically mean each agent has an independent persisted conversation history.
AgentCore Memory adds managed short-term and long-term memory. It can share memory across agents and apply strategies for preferences, facts, and summaries. Applications decide what records are authoritative and how deletion and user scoping work.
GraphN separates execution traces, knowledge bases, and object storage. It does not publicly claim a managed equivalent to AgentCore's cross-session long-term memory. Its knowledge base is better understood as controlled document retrieval.
That makes Memory a genuine reason to prefer AgentCore when personalized cross-session recall is central. It also adds governance questions:
- Which user or tenant owns a memory?
- Can a user inspect, correct, and delete it?
- Does a new agent version inherit prior memories?
- Are memory extraction model calls auditable?
- Can sensitive tool output become a durable memory?
Runtime isolation
AgentCore Runtime is a serverless hosting environment for agents and tools. AWS documents dedicated CPU, memory, and filesystem resources per session, extended runtime support for asynchronous agents, built-in authentication, and agent-specific traces.
This is a broader execution unit than a GraphN function. An AgentCore session can run the agent application itself, including framework code and tools. GraphN functions provide bounded deterministic logic in a managed isolated environment.
The boundaries fit different code:
- AgentCore Runtime is appropriate when a custom agent application needs a managed session environment.
- GraphN functions are appropriate for bounded deterministic logic within a managed workflow.
- Long-lived services, databases, and externally governed APIs should remain explicit remote dependencies in either design.
Do not translate an isolation label directly into a compliance conclusion. Review the documented tenancy boundary, egress, image provenance, credential handling, runtime duration, and data cleanup against the threat model.
Gateway and tool integration
AgentCore Gateway can convert APIs and Lambda functions into MCP-compatible tools and connect existing MCP servers. AgentCore Identity handles inbound and outbound authentication, including external identity providers and OAuth/API-key flows for downstream services.
GraphN lets teams register MCP servers as workspace resources and invoke selected tools from agents or explicit workflow steps. Functions can call platform services, and secrets provide credential bindings.
AgentCore's advantage is AWS integration depth. Existing Lambda functions, API Gateway endpoints, IAM policies, and enterprise identity providers can become part of an agent tool plane without being redesigned as GraphN resources.
GraphN's advantage is that tool definitions sit beside workflow, model, knowledge, and function resources in one product. A builder does not need to understand a separate AWS resource graph to assemble a workflow.
For delegated tools, test the full identity chain. The runtime's role should not silently replace the user's authority when an action must be performed on behalf of that user.
Deployment and operations
AgentCore is serverless at the runtime layer, but the application still participates in AWS architecture:
- runtime and memory resources;
- IAM roles and policies;
- VPC and private-service connectivity;
- Gateway targets;
- identity-provider configuration;
- CloudWatch logs, traces, metrics, retention, and alarms;
- model endpoints, quotas, and regions;
- CI/CD for the agent package.
This is an advantage for an AWS platform team: the agent fits existing infrastructure-as-code, security review, cost allocation, and incident response.
GraphN's customer-facing deployment unit is the published workflow. Workspace resource versions, model selection, tool definitions, and execution history live in the platform. GraphN owns more underlying infrastructure; the customer writes less AWS-shaped integration.
The trade is not “serverless versus servers.” It is composable cloud services versus an opinionated application platform.
Observability
Strands includes OpenTelemetry-oriented traces, metrics, and logs for model and tool calls. When deployed on AgentCore Runtime with AWS's OpenTelemetry distribution, session attributes and export can be configured for AgentCore and CloudWatch views.
AgentCore observability documentation distinguishes default service metrics and logs from custom runtime telemetry. Runtime creates a service log group by default, while Memory, Gateway, and built-in tool resources require explicit log-destination configuration.
GraphN execution traces can include per-node results, timing, token usage, resource references, and errors. Logs and execution status are available through the app and CLI.
AWS provides the more composable telemetry plane; GraphN provides the more integrated workflow view. Evaluate whether operators can answer:
- Which user, session, workflow version, model, and tool produced this side effect?
- Did the error occur in the framework, runtime, gateway, identity exchange, model, or downstream API?
- Are memory and gateway logs enabled, not merely available?
- Can prompts and tool payloads be redacted before export?
- Can the same trace connect cross-account or on-premises tools?
Models and inference
Strands supports Amazon Bedrock by default and multiple providers including Anthropic, OpenAI, Google, Mistral, Ollama, llama.cpp, custom providers, and others depending on language and optional packages. AgentCore Runtime is also documented as model-agnostic.
GraphN similarly avoids a single proprietary model boundary but adds managed model infrastructure. Its models reference covers built-in open-weight chat and vision models, external OpenAI-compatible endpoints, and weight imports from Hugging Face or S3, including supported LoRA paths.
Choose the AWS stack when Bedrock's catalog, guardrails, private connectivity, and account controls are already standard or when the company model gateway remains separate. Choose GraphN when operating open-weight GPU serving and custom models is part of the same problem as workflow deployment.
Knowledge and files
AWS offers Bedrock Knowledge Bases, S3, OpenSearch, Aurora, DynamoDB, and other data services that a Strands agent can use directly or through tools. AgentCore Memory addresses conversational recall rather than replacing those document and business stores.
GraphN provides workspace knowledge bases and object storage as part of the platform. A workflow can ingest files, retrieve ranked text or multimodal chunks, and pass them to agents or functions without creating separate cloud resources.
AWS's approach wins on composability and fit with an established data estate. GraphN's approach wins on reducing the number of services a workflow team must provision and connect.
Authentication and secrets
AgentCore Identity can authenticate end users through providers such as Cognito, Okta, Entra ID, or Auth0 and manage outbound credentials for tools. IAM remains the policy foundation for AWS resources.
GraphN uses workspace membership and workspace-scoped API keys for platform resources. Secrets can be attached to agents, MCP servers, functions, and model endpoints without embedding values in definitions.
AWS provides finer integration with cloud principals, but also demands careful role design. GraphN provides a simpler workspace boundary, but external tools still need end-user or service authorization. In both systems, avoid granting a broad runtime identity merely because tool selection is dynamic.
Migration boundaries
Strands and AgentCore to GraphN
- Inventory Graph, Swarm, Workflow, tools, SessionManager, Memory, Gateway, identity, and data services separately.
- Map explicit graph behavior and supported handoffs to GraphN DSL steps.
- Move bounded trusted logic to functions and expose existing AWS services through MCP or APIs.
- Do not migrate AgentCore Memory records into a knowledge base without defining semantics and consent.
- Register models, secrets, knowledge, and storage as workspace resources.
- Replay sessions and test identity propagation and side-effect idempotency.
GraphN to Strands and AgentCore
- Export workflow YAML and linked resources.
- Recreate control flow as a Strands Graph, Swarm, or application Workflow.
- Select session and memory implementations.
- Package the agent for Runtime and define IAM, networking, and identity providers.
- Convert functions and MCP servers into tools or Gateway targets.
- Map knowledge and files to AWS data services and configure observability for every AgentCore resource.
Choose Strands Agents and AgentCore when
- AWS accounts, IAM, VPCs, CloudWatch, and infrastructure-as-code are organizational standards.
- Agent code should remain Python or TypeScript and use Graph or Swarm abstractions.
- A framework-neutral managed runtime is useful.
- Managed long-term memory and an MCP gateway are first-class needs.
- Existing Lambda, API, Bedrock, and AWS data resources should remain authoritative.
Choose GraphN when
- Builders need one visual and YAML workflow definition.
- Agent, tool, function, model, knowledge, file, and secret resources should share a workspace lifecycle.
- Managed open-weight and custom-model GPU serving is required.
- Bounded workflow Python should use managed isolated function execution.
- The team wants to consume an agent application platform rather than design an AWS agent-service topology.
A proof of concept for platform teams
Implement a support workflow that:
- maintains one session and one long-term preference;
- retrieves private documents;
- calls a Lambda or external API through MCP;
- executes deterministic Python;
- uses two models;
- pauses for approval;
- returns structured output.
Then revoke the user, rotate the outbound credential, restart the runtime, delete the remembered preference, disable one telemetry destination, and fail the model endpoint. Count not only code changes but also IAM policies, resources, dashboards, and recovery steps.
Review what GraphN operates across the workflow lifecycle, its core concepts, security FAQ, models, and API when defining the comparison boundary.
Related comparisons
- GraphN vs Google ADK and Agent Platform — Google Cloud sessions, memory, IAM, and runtime
- GraphN vs Microsoft Agent Framework — Azure-hosted agents and Entra identity
- GraphN vs Dify — visual application authoring and open-source self-hosting
Primary sources
- Amazon Bedrock AgentCore overview
Defines AgentCore's composable Runtime, Memory, Gateway, Identity, tools, policy, and observability services.
- Amazon Bedrock AgentCore Runtime
Documents runtime session isolation, framework support, deployment, and execution characteristics.
- Amazon Bedrock AgentCore observability configuration
Describes CloudWatch-based observability configuration and the telemetry boundary evaluated here.
- Strands Agents multi-agent patterns
Defines Strands Graph, Swarm, and Workflow patterns used in the orchestration comparison.
- Strands Agents session management
Documents Strands session managers, persistence, and restoration behavior.
- GraphN core concepts
Defines GraphN workspaces, reusable resources, publishing, and execution concepts.
- GraphN models reference
Documents GraphN's built-in, imported, and custom model boundary.