The agent loop is now a deployable artifact

Until now the agent loop ran in-process: your agents executed inside the same Node process as the dashboard. This release pair (v1.71 and v1.72) breaks that coupling. The loop now ships as @vocion/agent-runtime, a standalone artifact with one HTTP contract (POST /invocations streaming SSE, GET /ping) that runs anywhere: a laptop process in dev, AWS Bedrock AgentCore Runtime in the cloud. Same bundle, different host.

What's new

• packages/agent-runtime: the loop as a generic artifact. No agent definitions, no database access. Every invocation carries the compiled definition (prompt, subagents, tool catalog), mounted files, and a signed tenant claim.
• Tools still execute in core. Catalog entries become transport tools that POST back to the claim-verified endpoint (/api/internal/agent-tools). Side-channel events (documents, approval gates, retrieval progress) return with each result and re-enter the run's stream.
• The event contract is frozen. The SSE stream is the same AgentEvent shape the chat UI already consumes. The UI cannot tell which host ran the loop.
• First production cutover. The sales assistant now declares harness: { provider: runtime } in workspace YAML and runs on the deployed artifact, tool round-trips included.
• CI deploys. A path-filtered GitHub Actions workflow builds the arm64 image and deploys it on pushes to main: typecheck and agent tests, OIDC credentials, build, deploy, smoke test.

Why we built it

An in-process loop means every agent shares the dashboard's process, deploy cadence, and failure domain. Moving the loop behind a contract makes where it runs a per-agent decision. The workspace schema now exposes it directly: harness.provider selects local (in-process, still the default), agentcore (the AWS-managed harness), or runtime (the BYOA artifact). Flipping one YAML field moves an agent between hosts, and the chat experience does not change.

How to use it

Run the artifact locally and point core at it:

npm run dev -w @vocion/agent-runtime        # serves :8080

Then opt an agent in from its workspace YAML:

# workspace/<org>/agents/sales-assistant.yaml
harness:
  provider: runtime

Core dispatches that agent's runs to the artifact; everything else keeps using the in-process loop. To verify end to end, run the smoke script from packages/core with Next dev and Postgres up:

npx dotenv -c -- tsx src/scripts/smoke-runtime.ts

Deploying to AgentCore Runtime (us-west-2) is three scripts:

ENV=dev bash infra/agentcore/provision.sh      # once: ECR, role, Memory, SSM
ENV=dev bash infra/agentcore/deploy-runtime.sh # bundle, arm64 image, ECR, runtime READY
ENV=dev bash infra/agentcore/smoke-invoke.sh   # streamed-done assertion

Core targets the deployed runtime when VOCION_AGENT_RUNTIME_ARN is set; unset, it falls back to VOCION_AGENT_RUNTIME_URL (default http://localhost:8080). Two escape hatches are built in: VOCION_DISABLE_RUNTIME=1 falls the fleet back to the in-process loop, and rollback is update-agent-runtime with any previous image tag in ECR (tags are <git-sha>-<timestamp>).

One current boundary worth knowing: deployed tool calls require a cloud-reachable core (VOCION_TOOL_ENDPOINT_URL). Until vocion-core itself is deployed, cloud runs are loop plus model only, and tool calls fail gracefully as tool errors the model can see.

What's next

• Conversation memory on the runtime host: AgentCore Memory sessions and long-term recall (shipped right behind this in v1.73 and v1.74; separate post).
• The multi-tenant lift: the roadmap's vocion-cloud phase builds on exactly this separation.

Links

• GitHub releases: https://github.com/vocion/vocion-core/releases/tag/v1.71.0 and https://github.com/vocion/vocion-core/releases/tag/v1.72.0
• Dashboard surface: /dashboard/chat (runs are indistinguishable by design)
• Code: packages/agent-runtime/, infra/agentcore/