Strands Agents

The trait that decides it is having the same SDK in both languages your team already uses. Most agent frameworks make you pick a language and then bolt a service boundary between your backend engineers and whoever writes the agent. Here the abstractions match across Python and TypeScript, so one design review covers both and nobody is translating patterns by hand.

It runs in your process, which is excellent for debugging and unhelpful for anything that has to survive being switched off. Pick it for agents inside your services. Pick LangGraph when a run must outlive the process.

The design decision that makes this pleasant is also the one that removes your safety margin. The loop runs in your process rather than on managed infrastructure, command execution is a listed capability, and no isolation layer appears in the documentation. Whatever credentials that process holds, the agent effectively holds, and a service account is usually generous.

Run agent workloads under a separate identity with its own scoped permissions. What it does right: execution limits are a first-class feature, so a loop that will not terminate is stopped by the framework rather than by your billing alert.

1. Control flow is delegated to the model, which chooses among tools rather than traversing a graph an engineer drew, so behaviour improves with model capability and cannot be constrained the way an explicit graph can. 2. Determinism is recovered through hooks and steering, which are the documented points where code re-enters the loop. 3. Multi-agent structure is offered as named patterns, swarm and agent-as-tool, rather than as bespoke wiring.

No benchmark accompanies the SDK. The architecture is an explicit bet that model capability keeps rising, which is a defensible bet and worth naming as one.

There is no mystery about how this is funded. A hyperscaler gives away the orchestration layer because it sells the compute underneath, and its own model service is the first provider named in the list. The neutral provider support is real and it is also the price of adoption; nobody would take a single-vendor SDK, and the default path still runs through the parent's meter.

Moat: the parent's existing enterprise relationships, which is the most durable distribution on this board. Likely risk is not failure but deprecation, which that company does on a schedule. Position: long, with a migration plan written down.

This is the rare row where procurement is a formality. There is no per-person charge, so sixty engineers cost nothing beyond model consumption, and the organisation maintaining it is one our legal team has already papered, which means no new vendor assessment and no new questionnaire cycle.

It runs unattended, so agents become pipeline steps producing artefacts we can review, and observability is described as part of the framework rather than a separate purchase. Onboarding is about a week for a mid-level engineer, since the model-driven style needs unlearning. Approved.

Apache-2.0 and genuinely dual-published, so I get the same thing from pip or npm without one of them being a neglected port. Ollama sits in the first-class provider list next to the hosted vendors, which means running the whole loop against my own hardware is a supported configuration rather than something I discover in a forum thread.

It works both directions on MCP, consuming my servers and exposing its own, and hooks let me interpose code wherever I want to watch or veto a step. That is the difference between a library I use and a library I own. Rare praise from me for something a hyperscaler shipped.