Awaken Agents · Agent application infrastructure

Source available · pre-release Apache-2.0

Build and run your AI Agent application.

Publish an Agent, connect your application, and follow its work. Choose where it runs and which data and tools it may use.

Run the Agents quickstart View and star on GitHub
Migrating an existing app? Check the compatibility surface and known differences

For Agent application developers and enterprise engineering teams.

Awaken Console · captured locally

The overview turns setup into five visible steps: connect a model, publish an Agent, run a Session, review the result, then connect an application.
Build and publish in Console Give the Agent a readable name, choose a runnable model and task, test the draft, then review the exact publication change.
Connect a model before you build Verify a provider credential and endpoint, import its model catalog, and expose only models the runtime can execute.
Connect through the protocol you use Open the protocol-specific guide, create the right API key for protected deployments, and inspect the same Session in Console.
Turn a tested Agent into repeatable work Each scheduled or manual trigger creates its own inspectable Session, with a direct path from the run to its result.

Captured from the local Awaken v1.0.0-dev Console at revision cadf3816ab4003e977387be2f700ce03c0455e04. Uses @awaken/ui 0.8.0 and controlled local setup data; no customer activity or deployed release is implied.

Choose deployment or Cloud hosting

When to choose Awaken

Use Awaken when your product needs managed Agent execution.

Start by creating an Agent, adopting a supported Agent, or connecting behavior you already own. Your application keeps its experience and business rules; Awaken runs the Agent.

Embed an Agent in your product

Connect a backend, web interface, copilot, or Agent-to-Agent client to one published Agent.

Keep work beyond one connection

Create and reopen a durable Session from committed events instead of tying work to one request or browser.

Choose execution without forking the product

Use Native execution, a supported ACP runtime, or a remote A2A Agent behind the same Session authority.

Control and grow the operating boundary

Start all-in-one, then split Control, Coordinator, and Workers when isolation, capacity, or ownership requires it.

A short-lived prompt, a trusted one-off local script, or a fully delegated managed service may not need Awaken. Choose it when Session continuity, controlled execution, or reusable application infrastructure is part of the product requirement.

First successful run

Run and inspect one Session.

  1. 1

    Start

    Run the local AllInOne service with a durable data directory.

  2. 2

    Publish

    Connect a model, publish one Agent, and create a Session.

  3. 3

    Verify

    See agent.message and session.status_idle, then reopen the committed events after restart.

Run the Agents quickstart
Explore execution and application responsibilities

System ownership

Your application owns the product. Awaken owns Agent execution.

The current Awaken source implements the ownership model below. The documentation defines exact APIs, schemas, deployment procedures, and compatibility versions.

Control

Owns Agent and Environment definitions, immutable revisions and publications, IAM, and credential references.

Coordinator

Owns executable projections, durable Sessions and Runs, dispatch, committed events, and public replay.

Worker + Runtime

The Worker claims fenced work and owns Sandbox and process lifetime. Its embedded Rust Runtime executes Agent loops, tools, permissions, typed state, and atomic steps; it is not a second service authority.

Publication and recovery sequence

  1. 01

    Publish immutable Agent and Environment revisions.

  2. 02

    Create a Session that freezes the exact executable references.

  3. 03

    Record work and project an idempotent dispatch in the Coordinator.

  4. 04

    Let an eligible Worker claim the dispatch and execute inside its Sandbox boundary.

  5. 05

    Commit events and state through the Session authority before they become public replay.

  6. 06

    Reconnect or recover from committed Session facts under the configured policy.

Failure outcomes

Permission required

Commit an awaiting state and durable resume ticket; continue only after the decision.

Worker interrupted

Use committed facts and claim fences to recover eligible work without creating another Session owner.

External outcome ambiguous

Record an indeterminate terminal cause. Never project uncertain execution as success.

Read the full architecture and recovery model

Product work

Use Awaken for Agent execution and Session management.

Your application owns its experience, domain state, workflow, acceptance, and commercial relationship. Awaken manages the Agent lifecycle.

Ship one real Agent application

Publish an Agent, create and reopen the same Session, connect resources and permissions, and operate execution without assembling another backend.

Agent publication · Session and events · resources · Worker and Sandbox

Keep existing application investment

Retain the tested official SDK model and connect web, copilot, or Agent-to-Agent surfaces to the same published Agent instead of copying it.

Managed Agents · AI SDK · AG-UI · A2A

Keep differentiated Agent behavior

Choose Awaken Native execution, a supported ACP runtime, or a remote A2A Agent without creating another Session authority.

Native · ACP · outbound A2A

Run inside enterprise boundaries

Place control, Session data, credentials, model routes, Workers, and Sandboxes inside the approved infrastructure and responsibility boundary.

Self-hosted · enterprise delivery · hosted preview

Failure handling

Recover from committed Session state.

Awaken follows committed facts and an explicit recovery policy. It does not assume every external side effect is safe to replay.

A user reconnects

Reopen the same Session from committed events instead of depending on one browser or process.

Durable Session

A Worker or process stops

Recover eligible work from committed facts and continue under the configured recovery policy.

Recovery boundary

A tool requests sensitive action

Allow, deny, or suspend for a human decision before the tool executes.

Permission and HITL

An operator needs an explanation

Inspect events, traces, and audit history across the execution path.

Observability

Data and tools must stay inside

Place control, Session data, credentials, Workers, and Sandboxes in the approved infrastructure boundary.

Self-hosting
Review Managed Agents compatibility and differences

Managed Agents compatibility

Keep the application contract and choose how Agents run.

Anthropic Managed Agents defines a useful application contract. Awaken implements a tested baseline, then adds explicit client, execution, model, and deployment choices around one Agent and Session authority.

Adopt with the official SDK model

Managed Agents baseline

Use the official Managed Agents API and SDK resource model.

Awaken extension

Point a reviewed SDK version to Awaken, configure Awaken authentication, and keep the named compatible request and response shapes.

What this changes: Check supported requests, required selectors and known differences

Connect more than one application surface

Managed Agents baseline

Managed Agents clients enter through the Managed API.

Awaken extension

Managed Agents, AI SDK, AG-UI, and A2A project the same published Agent and committed Session history.

What this changes: Reuse one Agent across backend, web, copilot, and Agent-to-Agent products

Choose the execution behavior

Managed Agents baseline

Use a managed sandbox or self-hosted environment worker inside the Anthropic service model.

Awaken extension

Select Native execution, a supported ACP Agent runtime, or a remote A2A endpoint without changing the client contract.

What this changes: Preserve existing Agent behavior and select the right execution path per product

Choose who owns the platform boundary

Managed Agents baseline

The service control plane and persistent service are operated by Anthropic.

Awaken extension

Deploy and operate the API, Session data, credentials, model routes, Workers, and Sandboxes yourself or through an AwakenWorks delivery mode.

What this changes: Choose where the API, Session data, credentials and execution run

Technical guides

Choose the guide for your current decision.

Run the quickstart first. Use the documentation to review compatibility, architecture, recovery, deployment, or Runtime internals.

Migrate an existing client

Check reviewed SDK versions, supported resources, required selectors, and known differences before changing an application.

Review compatibility

Review authority and recovery

Follow publication, Session, dispatch, Worker execution, committed facts, failures, and recovery through their owning boundaries.

Read the architecture

Choose a deployment boundary

Plan AllInOne or split services, data and credential custody, Workers, Sandboxes, observation, backup, and operating ownership.

Open the self-hosting guide

Understand the runtime boundary

Separate Agent execution from the Sessions, Workers, Sandboxes, protocols, and operations around it before choosing an integration path.

Define Agent Runtime

Run one Session before planning a larger deployment.

Evaluate the source code independently; a stable release package is not yet available. Contact us if you need help with integration, deployment or support.

Run the Agents quickstart Enterprise deployment services