Stop Reaching for Python: Strands Agents TypeScript SDK Just Hit 1.0

A lot of production codebases are TypeScript. A lot of agent frameworks are Python. You either rewrite your stack or build a bridge between two languages. Strands Agents just shipped 1.0 of the TypeScript SDK, so now you don't have to! It's the full framework, and it's great. And it does things Python can't, like running agents in the browser.

The Python SDK has been in production since May 2025. This is the same model-driven approach, now with full TypeScript types and Zod-validated tools.

Full disclosure, I'm a Developer Advocate for AWS. Strands is an open source project from AWS. I've been building with the Python SDK for months, so I was curious how the TypeScript version compares. So far, it's been great.

Get Started

Install the SDK:

npm install @strands-agents/sdk

Then check out the quickstart guide to build your first agent in under 5 minutes. The GitHub repo has examples for every feature, and the API docs cover the full surface area.

• TypeScript quickstart
• GitHub repo
• API docs

Let me show you how it works!

Two Lines to a Working Agent

The API is small on purpose. Create an agent, then you invoke.

import { Agent } from '@strands-agents/sdk'

const agent = new Agent({ systemPrompt: 'You are a helpful assistant.' })
const result = await agent.invoke('What makes TypeScript great for building agents?')

console.log(result.lastMessage)

Bedrock is the default model provider. If you want OpenAI, Anthropic, Google, or anything that works with the Vercel AI SDK, you swap one import:

import { Agent } from '@strands-agents/sdk'
import { OpenAIModel } from '@strands-agents/sdk/models/openai'

const model = new OpenAIModel({ api: 'chat', modelId: 'gpt-5.4' })
const agent = new Agent({ model, systemPrompt: 'You are a helpful assistant.' })

You don't need config files or provider abstraction layers. Swap the model and go.

Zod Tools

This is where working with TypeScript really shines. You define a tool with a Zod schema, and you get runtime validation plus full type inference at compile time. The model can't pass garbage to your tool without Zod catching it.

Here is a GitHub lookup tool in about 30 lines:

import { Agent, tool } from '@strands-agents/sdk'
import { z } from 'zod'

const githubRepo = tool({
  name: 'get_github_repo',
  description: 'Get info about a GitHub repository.',
  inputSchema: z.object({
    owner: z.string().describe('Repository owner'),
    repo: z.string().describe('Repository name'),
  }),
  callback: async (input) => {
    const res = await fetch(`https://api.github.com/repos/${input.owner}/${input.repo}`)
    const data = await res.json()
    return `${data.full_name} — ⭐ ${data.stargazers_count} stars`
  },
})

const agent = new Agent({
  tools: [githubRepo],
  systemPrompt: 'You are a developer assistant.',
})

The input parameter in that callback is fully typed. Your editor knows input.owner is a string. You don't need any or type casting.

The SDK also ships with built-in tools for bash, file editing, HTTP requests, and notebooks. Your agent can read files, hit APIs, and run shell commands without you writing any tool code:

import { Agent } from '@strands-agents/sdk'
import { bash } from '@strands-agents/sdk/vended-tools/bash'
import { fileEditor } from '@strands-agents/sdk/vended-tools/file-editor'
import { httpRequest } from '@strands-agents/sdk/vended-tools/http-request'
import { notebook } from '@strands-agents/sdk/vended-tools/notebook'

const agent = new Agent({
  tools: [bash, fileEditor, httpRequest, notebook],
  systemPrompt: 'You are a helpful coding assistant.',
})

MCP

If you're already using MCP servers, they plug right in. I tested this with the filesystem MCP server and it worked well.

import { Agent, McpClient } from '@strands-agents/sdk'
import { StdioClientTransport } from '@modelcontextprotocol/sdk/client/stdio.js'

const mcp = new McpClient({
  transport: new StdioClientTransport({
    command: 'npx',
    args: ['-y', '@modelcontextprotocol/server-filesystem', process.cwd()],
  }),
})

const agent = new Agent({ tools: [mcp] })

One import for any MCP-compatible tool server.

Streaming

There are Async iterators you can use to generate chunks and stream them back to the user.

const agent = new Agent({ systemPrompt: 'You are a creative storyteller.', printer: false })

for await (const event of agent.stream('Tell me a short story about a brave toaster.')) {
  if (
    event.type === 'modelStreamUpdateEvent' &&
    event.event.type === 'modelContentBlockDeltaEvent' &&
    event.event.delta.type === 'textDelta'
  ) {
    process.stdout.write(event.event.delta.text)
  }
}

The event type checking is verbose, but that's TypeScript gets it done.

It Runs in the Browser

I don't think many people think about this, but you can run agents in the browser if you'd like.

And of course, you can't run the Python SDK in the browser, at least not natively.

There's a demo in the strands-agents/sdk-typescript repo where you chat with an agent and it builds a live HTML canvas in real time. The agent runs entirely client-side.

That makes a bunch of things possible that weren't before. For example you can run local-first tools where the agent runs on the user's machine. Interactive assistants embedded in your app without a server round-trip. If you didn't want to make that server round-trip you could even have the model run locally.

I cloned the demo and had it running quickly.

git clone https://github.com/strands-agents/sdk-typescript.git
cd sdk-typescript/strands-ts/examples/browser-agent
npm install && npm run dev

Multi-Agent Patterns

The SDK ships with three ways to combine agents. Agent-as-tool is the simplest, where you pass one agent into another's tools array. Graph gives you explicit dependencies between agents. Swarm lets agents decide at runtime which agent handles the next step.

There's also a plugin system with 15+ lifecycle events, structured output with Zod validation, session persistence with pluggable storage, cooperative cancellation via AbortSignal, and OpenTelemetry tracing. I haven't tested all of these yet, but the plugin system is simple to use.

The SDK is open source. If you build something with it, I want to see it. The browser runtime especially. I'm curious where people take it.

---

Watch the Full Video

If you prefer video format, here's a quick walkthrough of the TypeScript SDK and its key features:

Comments

[PEACEBINFLOW]

The browser runtime is the detail that's going to stick with me, because it quietly changes the shape of what you can build. Most agent frameworks assume a server-side execution model — the agent lives near the APIs and databases it needs to call. But running an agent entirely client-side opens up a different category of use cases where the agent's tools are local to the user's machine: reading files they've selected, manipulating a canvas they're looking at, reasoning about their current browser state without a round trip.

What's interesting is that this flips one of the common security concerns about agents. Instead of "how do I prevent this agent from accessing things it shouldn't on my server," the question becomes "what can this agent do with the permissions the browser already grants to the page it's running on?" The sandbox is different. An agent running in a browser tab can't access your database, but it can access whatever that tab can see — local state, user input, DOM. The attack surface shifts from infrastructure to the user's session.

I'm curious whether the SDK provides any guardrails specific to the browser context, or if it's up to the developer to reason about what an agent-in-a-tab should and shouldn't be allowed to do. That feels like the kind of thing that could be obvious in a demo and surprising in production, especially if the agent can call tools that make outbound requests.