Skip to main content
AgentDeck

AgentDeck SDK

Agentic software should feel like software.

Build agents, tools and workflows as normal software. AgentDeck gives them one execution model you can observe, control and extend.

CI Release Python License Docs

pip install agentdeck-sdk

The rest of this page builds one real application, a step at a time. Its name is Jack, he answers questions about AgentDeck, and he is the assistant running on agentdecksdk.com right now. Everything below is his actual source.

Let's build Jack

An agent is a declaration. A Deck is where an agentic application comes together.

from agentdeck import Agent, Deck

jack = Agent(
    name="Jack",
    instructions="Help developers build with AgentDeck.",
)

deck = Deck(agents=[jack])

Jack needs to know things

Tools do work; agents make decisions. A tool that takes a Context stays an ordinary function, because the model is offered only the arguments it can actually choose: it never sees docs.

from agentdeck import Agent, Context, Deck

def search_docs(query: str, docs: Context[DocsCorpus]) -> str:
    """Find AgentDeck documentation pages matching a query."""
    return docs.data.search(query)

def read_doc(slug: str, docs: Context[DocsCorpus]) -> str:
    """Read one AgentDeck documentation page in full, by its slug."""
    return docs.data.pages[slug]

def read_changelog(subject: str, docs: Context[DocsCorpus]) -> str:
    """Read AgentDeck's release history, by version or by topic."""
    return docs.data.changelog(subject)

jack = Agent(
    name="Jack",
    instructions="Help developers build with AgentDeck.",
    tools=[search_docs, read_doc, read_changelog],
)

deck = Deck(agents=[jack], context=DocsCorpus)

context=DocsCorpus is the type; the instance goes in per run. Declaring it makes build() check every Context[...] in the catalog before a question is ever asked, so the wrong type raises at startup rather than mid-answer.

Everything becomes one execution tree

Run him, and the run is a first-class thing with an ordered event log:

async with deck:
    async for event in deck.stream("Jack", "how do I pause a run?", context=corpus):
        print(event.kind)  # run.started, tool.call.started, text.delta, run.completed

Every managed invocation appends to that one log, whatever started it. Status is folded from the log rather than stored beside it, so there is no second source to disagree with.

Execution you can steer

A Run is the root execution, and control belongs to the handle rather than to a separate lifecycle API:

run = await deck.runs.start("Jack", question, context=corpus)

await run.pause()
await run.resume()
await run.cancel()

await run.answer({"approved": True})   # finish a run parked at an interrupt

deck.runs.get(id) rehydrates that handle in another process, so a run paused by a web request can be resumed by a worker. Two handles on one run always agree: the durable store is the only thing either reads.

Jack is real, and you can use him now

The panel on agentdecksdk.com is that agent. Ask it something about AgentDeck and it searches these docs, reads the pages it finds, and cites them.

He is three tools over one Context[DocsCorpus], streaming the run's own canonical events to the browser over SSE with no translation layer on either side, and he is the thing serving the site: an origin check, a per-day quota, a token ceiling, and an allowlist deciding which event kinds a browser may see are all parts a public endpoint needs and a demo skips.

How Jack is built walks the whole application, and Implementation notes records each decision and the alternative it beat. The source is examples/jack.

He is also the honest test of the pitch. If "agents you have to operate" meant anything, it had to survive being operated.

Where your definitions live

Everything you define lives in a .agentdeck/ directory next to where you run. The path is the registration: no catalog file, no __init__.py, no decorator to remember.

.agentdeck/
├── agents/greeter/agent.py            # an Agent(...)
├── workflows/new_booking/workflow.py  # a Workflow(...)
└── skills/parse-request/              # SKILL.md + optional scripts
async with Deck.from_project() as deck:   # discovers ./.agentdeck, fails fast
    result = await deck.run("Greeter", "hello")

Deck discovers, compiles and validates all of it before the first turn: a missing skill, an unknown MCP name or a workflow that cannot compile fails at build(), not in production.

Runnable projects are in examples/: a chat agent with a tool, a workflow that pauses for human approval, an existing LangGraph agent wrapped without rewriting it, and Jack. All are built by the test suite, so none can quietly stop working.

You build the behavior. AgentDeck manages the machinery.

Your code stays about the behavior and the structure of your application. Everything a run needs around it already has a place, and they were designed to work together: less machinery to build today, and nothing to retrofit when you need the next one.

You own AgentDeck owns
agents, tools, workflows Events. One ordered stream of what happened.
what progress means Reporting. Progress and status, sent from inside the work.
when work should stop Control. Execution paused, resumed or cancelled at safe points.
when a person decides Interaction. Branches that wait for external input.
business state State. Sessions that outlive a single call.
your UI and integrations Surfaces. Observers, HTTP and your UI read the same run.

The complexity is still there. It just lives in the layer built for it.

AgentDeck owns configuration; the OpenAI Agents SDK and LangGraph own execution. There is no agent loop here, no graph engine, and no reimplementation of either: an Agent compiles to an SDK agent, a Workflow compiles to a LangGraph graph, and each is run by its own engine. You keep native access when you need it.

Who it is for

You want this if you are putting agents somewhere they have to keep working: several agents and workflows in one project, a chat surface and a batch path over the same definitions, runs you need to inspect afterwards, approvals that outlive the process that asked for them.

You do not want this if you are writing one script that calls one model. Use the Agents SDK directly, and come back when the wiring around it has become the work. You also do not want it if you have already built your own harness: AgentDeck is opinionated about project layout and configuration, and those opinions are the product.

What it deliberately does not do

  • No DSL. Definitions are Python. There is no YAML agent format, and there will not be one.
  • No execution engine of its own. Bugs in the agent loop or in graph execution belong upstream, and improvements there arrive without agentdeck doing anything.
  • No sandbox. Tools, skills and workflow nodes are ordinary Python in your process, and a model-chosen tool call is trusted by design. See SECURITY.md before you give an agent something destructive.
  • No auth, no multi-tenancy, no hosted control plane, no marketplace. namespace labels a run; it does not authenticate anyone. Put a real gateway in front of the HTTP surface.
  • No model routing, evaluation framework, or prompt management. One OpenAI-compatible endpoint per process, configured by environment.

Install

pip install agentdeck-sdk              # or, with the HTTP surface: agentdeck-sdk[serve]
export OPENAI_MODEL=gpt-4.1-mini OPENAI_API_KEY=sk-...

The distribution is agentdeck-sdk; the import stays agentdeck. OPENAI_BASE_URL points it at any OpenAI-compatible endpoint instead (a gateway, vLLM, Ollama). Extras: serve for the HTTP surface, durability for the Postgres checkpointer and event store (SQLite ships in base, so durable=True works out of the box), redis for Redis-backed sessions or event log, observability for Langfuse tracing.

Contributing to agentdeck itself is a different setup: see CONTRIBUTING.md.

Documentation

The full docs are at agentdecksdk.com:

If AgentDeck is useful to you, a star helps other developers find it.

Project

AgentDeck is beta software under active development; breaking changes are listed in CHANGELOG.md.

Contributors

Contributors

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

agentdeck_sdk-4.0.3.tar.gz (1.3 MB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

agentdeck_sdk-4.0.3-py3-none-any.whl (282.6 kB view details)

Uploaded Python 3

File details

Details for the file agentdeck_sdk-4.0.3.tar.gz.

File metadata

  • Download URL: agentdeck_sdk-4.0.3.tar.gz
  • Upload date:
  • Size: 1.3 MB
  • Tags: Source
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/7.0.0 CPython/3.13.14

File hashes

Hashes for agentdeck_sdk-4.0.3.tar.gz
Algorithm Hash digest
SHA256 5f26771c834e6654e75af7b8a015c71ce5e545afa5e31178ca16ff8d8f0dd087
MD5 cb2b0f661b8edf358c0cb5f7b7fe1eeb
BLAKE2b-256 778795dc2fa892492ce1d9e32722f32f8ca481bf971534ffe94503861d90dbeb

See more details on using hashes here.

Provenance

The following attestation bundles were made for agentdeck_sdk-4.0.3.tar.gz:

Publisher: release.yml on agentdecksdk/agentdeck

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file agentdeck_sdk-4.0.3-py3-none-any.whl.

File metadata

  • Download URL: agentdeck_sdk-4.0.3-py3-none-any.whl
  • Upload date:
  • Size: 282.6 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/7.0.0 CPython/3.13.14

File hashes

Hashes for agentdeck_sdk-4.0.3-py3-none-any.whl
Algorithm Hash digest
SHA256 5752b0f27681a177be94fb84cb4481f6a7ddf8d1bd0a46fae5f2400c84bc99e7
MD5 88e02902917e33aaced140eec8a975f6
BLAKE2b-256 5c55d4cb68cceb7fb4463092a776eb0c9f0589a96c66233bdea5a31bb5ca5e30

See more details on using hashes here.

Provenance

The following attestation bundles were made for agentdeck_sdk-4.0.3-py3-none-any.whl:

Publisher: release.yml on agentdecksdk/agentdeck

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page