core-agent

Autonomous quickstart

Mon, 01 Jan 0001 00:00:00 +0000

15 minutes from core-agent installed → a working unattended agent that watches a real thing and reports back.

Prefer to have an agent walk you through this? The autonomous-setup skill covers the same material in workflow form, including the multi-agent decomposition path. Install once, then say “set up an autonomous monitor for me” and the agent walks the 9-step runbook with you.

What “autonomous” means here

The interactive TUI assumes an operator at the keyboard reacting to model output. Autonomous mode flips that: you describe a goal up front, hand the agent a set of tools and a budget, then walk away. The agent works until it decides it’s done, hits a budget cap, or you cancel it. The session log is the audit trail.

cli-setup skill

Mon, 01 Jan 0001 00:00:00 +0000

The cli-setup skill walks a user through configuring core-agent for interactive use. It’s bundled in SKILLS/cli-setup/ at the repo root.

What it covers

The four customization layers, in order:

Provider + model — .agents/config.json
Personality — AGENTS.md
Skills — .agents/skills/<name>/SKILL.md
Tools — built-ins + MCP servers

Plus permission posture (ask / allow / yolo modes, allowlist patterns) and the verify-it-works step.

Triggers

The skill’s description lists the verbatim phrasings the agent will match. The most common:

Interactive quickstart

Mon, 01 Jan 0001 00:00:00 +0000

15 minutes from core-agent installed → a tailored agent your whole team can use.

Prefer to have an agent walk you through this? The cli-setup skill covers the same material in workflow form. Install once, then say “help me set up core-agent for my project” and the agent walks the four layers with you, writing files as you go.

What you’ll have at the end

A project-scoped agent that:

Knows what your project is (system prompt via AGENTS.md)
Has a reusable named procedure (a skill)
Asks before running anything risky (permissions in ask mode by default)
Is checked into the repo so every teammate gets the same agent

The running example is a “Go code-reviewer” for a hypothetical project. Adapt as needed.

System instructions

Mon, 01 Jan 0001 00:00:00 +0000

AGENTS.md is the most-impactful customization surface in core-agent. The model sees it on every turn. Get it right and the agent behaves consistently across operators and across sessions; get it wrong and the agent acts unpredictably regardless of what skills or tools you wire up.

This page covers the patterns that work, the failure modes to watch for, and how to iterate on an AGENTS.md instead of writing it once and hoping.

autonomous-setup skill

Mon, 01 Jan 0001 00:00:00 +0000

The autonomous-setup skill walks a user through configuring an unattended core-agent — single-agent monitor or multi-agent team. Bundled in SKILLS/autonomous-setup/.

What it covers

A 9-step runbook:

Decide if autonomous actually fits (vs interactive + attach)
Define the goal crisply
Pick single-agent or multi-agent shape
Bound the run with budget caps
Write AGENTS.md with unattended discipline
Set headless permission posture
Wire durable sessions
Write the Go driver
Test end-to-end before deployment

The runbook is non-linear; the agent picks references based on which path the user is on.

Getting started

Mon, 01 Jan 0001 00:00:00 +0000

Install

As a CLI (Go toolchain)

Requires Go 1.26 or newer.

go install github.com/go-steer/core-agent/cmd/core-agent@latest

The binary lands in $(go env GOBIN) (or $GOPATH/bin if GOBIN is unset). Make sure that’s on your $PATH.

As a pre-built binary (no Go toolchain needed)

Cross-compiled archives for linux/darwin × amd64/arm64 are published on the Releases page, signed via Sigstore keyless.

TAG=$(gh release view --repo go-steer/core-agent --json tagName -q .tagName)
OS=$(uname -s | tr A-Z a-z) # linux | darwin
ARCH=$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/')
gh release download "$TAG" --repo go-steer/core-agent \
 --pattern "core-agent_${TAG#v}_${OS}_${ARCH}.tar.gz"
tar xzf "core-agent_${TAG#v}_${OS}_${ARCH}.tar.gz"
./core-agent --version

The core-agent-tui remote client uses the same naming pattern (swap core-agent for core-agent-tui).

Skills

Mon, 01 Jan 0001 00:00:00 +0000

Skills are named, reusable procedures the agent invokes when the task matches the skill’s description. This page covers the design patterns: when to write a skill vs. an AGENTS.md rule, how to write a description that actually triggers, what belongs in the body vs. a references/ file, and how to test that a skill fires when you expect it to.

For the schema and discovery details (file locations, YAML frontmatter, allow/deny lists), see Reference → Skills. This page is the prescriptive companion.

Workflows

Mon, 01 Jan 0001 00:00:00 +0000

Worked examples of using core-agent interactively. Each one shows a full .agents/ configuration you can adapt and a walkthrough of running it.

If you haven’t done the Interactive quickstart yet, do that first — these examples assume you know how AGENTS.md, skills, and permission posture fit together.

Workflow 1 — Go code reviewer with MCP-backed web search

The marquee operator example. A code-reviewer agent that knows your house style, follows a documented review procedure, and can reach the web when it needs context on an unfamiliar library.

GKE multi-agent scenario

Mon, 01 Jan 0001 00:00:00 +0000

A worked multi-agent example for running unattended core-agent agents against a GKE fleet. Three coordinating agents — platform, operator, devteam — each with their own role, MCP servers, skills, and budget envelope. The scenario at the end shows them interacting around a real production-style workflow: a rollout that breaches an SLO and gets investigated and remediated through the team’s normal escalation path.

The team shape mirrors gke-labs/kube-agents. The MCP wiring, skills, and scenario are concrete to core-agent’s capabilities — you can adapt them to your fleet.

library-embedding skill

Mon, 01 Jan 0001 00:00:00 +0000

The library-embedding skill walks a Go developer through embedding core-agent in their own binary. Bundled in SKILLS/library-embedding/.

What it covers

A 5-step runbook:

Confirm the use case (CLI use vs library use)
Show the minimal embed (20-line “hello world”)
Identify which extension point the user needs
Show a full worked example for non-trivial embeddings
Discuss long-term maintenance (go.mod pinning, breaking-change policy)

The extension points covered include Prompter, custom tools, custom Provider, custom session.Service, Compactor / Checkpointer, BackgroundAgentManager, and RemoteAgentSpawner.

Providers

Mon, 01 Jan 0001 00:00:00 +0000

core-agent ships four model backends, all behind the same models.Provider interface. Pick one explicitly via model.provider in .agents/config.json or with the --provider CLI flag, or let env-based auto-detection pick.

Auto-detection

When model.provider is empty (the default), core-agent walks the environment in this order and picks the first match:

Vertex Gemini — fires when GOOGLE_GENAI_USE_VERTEXAI=true and GOOGLE_CLOUD_PROJECT is set
Gemini API — fires when GOOGLE_API_KEY or GEMINI_API_KEY is set
Anthropic — fires when ANTHROPIC_API_KEY is set

If none match, you get a clear error listing the env vars to set. Anthropic-via-Vertex is not auto-detected — it overlaps with Vertex Gemini in env vars, so you have to opt in explicitly with --provider anthropic-vertex or model.provider: "anthropic-vertex" in config.

Slash reference

Mon, 01 Jan 0001 00:00:00 +0000

Reference for every slash command and keybinding available in the interactive TUI. Type /help in any session for the operator-side version of this catalog.

For attach-mode (core-agent-tui remote client) commands, see Attach mode TUI.

Quick reference

Session control

Command	Aliases	Effect
`/help`		Print the command list + keybindings into the scrollback
`/clear`		Clear the local scrollback (session log is untouched)
`/quit`		Leave the TUI cleanly
`/interrupt`		Cancel the in-flight model turn (same as pressing Esc during a turn)
`/resume`		Resume a saved session from `<AgentsDir>/sessions/`
`/reload`		Re-walk `AGENTS.md`, skills, and MCP config on disk. Reports per-surface results inline (`Memory: ✓`, `Skills: ✓`, `MCP: ✗` with errors listed) so you can confirm an edit parsed cleanly. Live MCP server restart and system-prompt rebuild still require a daemon restart.

Status + observability

Command	Aliases	Effect
`/stats`		Session token totals, cost, duration, per-model breakdown
`/context`	`/boundaries`	Context-management activity: compactions, checkpoints, summarized chars, subtask cost
`/tools`		List the tools the agent has access to (built-ins + MCP + skills)
`/skills`		List loaded skills with their trigger descriptions
`/mcp`		List configured MCP servers and their status
`/subagents`	`/sub`	List background subagents spawned this session
`/memory`		Show the resolved `AGENTS.md` chain (user-global + project)

Context management

Command	Aliases	Effect
`/compact [focus]`	`/summarize`	Manually compact the session; optional `focus` biases what the summary preserves
`/done [note]`	`/checkpoint`	Write a task-boundary checkpoint; optional `note` becomes part of the handover record

Both run a summarizer LLM call (5-15s); the next turn picks up from the summary with prior history sliced. See Context management for the design.

Subagents and wrappers

Mon, 01 Jan 0001 00:00:00 +0000

Two ways to push work off the parent agent:

Agentic tool wrappers (agentic_read_file, agentic_grep, agentic_research, agentic_fetch_url) — synchronous, bounded, single-purpose. The parent calls them like any other tool; under the hood they spawn a focused subtask on a (typically cheaper) model and return only the digest. Raw tool output never enters the parent’s context.
Background subagents (spawn_agent, list_agents, check_agent, stop_agent) — asynchronous, longer-running, multi-turn. The parent dispatches a goal; the subagent works in its own session until done; alerts and completion summaries land back in the parent’s chat.

This page covers when to use each, how to actually get the model to use them (the model-side adoption story is non-trivial), and the failure modes worth designing around.

Why core-agent

Mon, 01 Jan 0001 00:00:00 +0000

If you’re building an agent in Go, your starting point is the Google Agent Development Kit (ADK). ADK gives you a model interface, a tool-calling loop, a session abstraction, and some streaming primitives. That’s roughly 30% of what a production agent needs. core-agent is the other 70% — the parts every team writes the second they take an ADK demo from “responds to my prompt” to “I’d let a real user touch this.”

Configuration

Mon, 01 Jan 0001 00:00:00 +0000

The `.agents/` directory

core-agent walks up from the working directory looking for a folder named .agents/, analogous to how git looks for .git. The first match wins. Everything core-agent reads or writes lives there:

.agents/
├── config.json # this file — provider, model, permissions, scope, telemetry, etc.
├── mcp.json # MCP server declarations (see MCP page)
├── skills/ # SKILL.md bundles (see Skills page)
└── sessions/ # one-shot transcripts; auto-written, safe to .gitignore

You don’t have to create .agents/ — without it, core-agent runs with built-in defaults and skips the project-specific bits (no transcripts, no MCP, no skills). It’s required only when you want to customize.

Cost efficiency

Mon, 01 Jan 0001 00:00:00 +0000

What actually moves the cost needle on core-agent sessions, in rough order of impact. Built-in price tracking and per-model breakdowns make the tradeoffs measurable rather than guesswork; this page covers how to read those signals and the patterns that consistently reduce cost without sacrificing capability.

For the mechanism details see Context management and Configuration → pricing.

The cost hierarchy

A rough sense of where dollars go on a typical coding session:

Driver	Typical share of session cost	Lever
Input tokens (cumulative across turns)	70-90%	Compaction, checkpoints, agentic wrappers
Output tokens	10-25%	Tighter `AGENTS.md` (“be concise”), structured output formats
Per-turn model rate	Multiplier on both	Model selection (Pro vs Flash for subtasks)
Subtask + compaction LLM calls	2-10%	Bounded by infrastructure, not operator-tunable

The input-token share is the killer. Every turn re-sends the entire conversation history to the model. By turn 30, you’re paying input-token prices for everything that came before, plus the new turn. The single biggest lever on cost is preventing that input-token total from growing without bound — which is exactly what compaction, checkpoints, and agentic wrappers do.

Built-in tools

Mon, 01 Jan 0001 00:00:00 +0000

The model-facing tool catalog core-agent registers by default, plus the optional lifecycle tools the runtime wires when the corresponding feature is enabled (checkpoints, ask, autonomous scheduling). For declaring third-party tools, see MCP servers. For writing your own tools from Go, see Library API.

The built-in catalog

Thirteen tools are registered by default. Each is configurable via the BuiltinTools struct in pkg/tools (library callers) or the --disable-tools flag / tools.disable config field (CLI users). Every call routes through the permission gate under the tool namespace — denying a tool by pattern keeps it from running even if it’s registered.

Library guide

Mon, 01 Jan 0001 00:00:00 +0000

This guide is for Go engineers embedding core-agent in their own binary. Where the user guide is about configuring the bundled CLI, this one is about extending the library — replacing the CLI’s defaults with your own UI, tools, providers, and runtime topology.

The full API reference lives in Library API. This guide is the narrative path through it, organized by extension point with worked examples for each.

Who this is for

You’re a Go engineer building one of:

MCP servers

Mon, 01 Jan 0001 00:00:00 +0000

core-agent integrates with Model Context Protocol servers via ADK’s mcptoolset. Declare servers in .agents/mcp.json; core-agent spawns or connects to them at startup, namespaces their tools, and routes every tool call through the permission gate.

`mcp.json` schema

{
 "version": 1,
 "servers": {
 "filesystem": {
 "transport": "stdio",
 "command": "mcp-server-filesystem",
 "args": ["--root", "/tmp"],
 "env": { "LOG_LEVEL": "info" }
 },
 "github": {
 "transport": "http",
 "url": "https://api.githubcopilot.com/mcp/",
 "headers": { "Authorization": "Bearer ${env:GITHUB_TOKEN}" }
 }
 }
}

Top-level fields:

Field	Type	Notes
`version`	int	Schema version. Currently `1`.
`servers`	object	Map of `name` → `ServerSpec`. The `name` becomes the tool namespace prefix.

`ServerSpec`

Field	Required when	Notes
`transport`	always	`"stdio"` or `"http"`.
`command`	`transport: stdio`	Executable to spawn.
`args`	optional, stdio	Argv tail.
`env`	optional, stdio	Extra env vars; layered on top of the parent env. Values support `${env:NAME}` interpolation.
`url`	`transport: http`	Streamable HTTP endpoint.
`headers`	optional, http	Custom headers. Values support `${env:NAME}` interpolation — useful for `Authorization: Bearer ${env:TOKEN}`.
`auth`	optional, http	Selects an authentication strategy that manages tokens for you instead of static headers. See Authentication below.

Validation runs at config load time. A server that mixes transports (e.g. both command and url) is rejected with a clear error before the agent starts.

Context management

Mon, 01 Jan 0001 00:00:00 +0000

Long agent sessions hit two failure modes the model can’t recover from on its own:

The context window fills up. Every turn appends to the prompt; eventually the next turn errors out with “context window exceeded.”
Raw tool output bloats the parent. A 5,000-line file read, a 200KB URL fetch, a grep with hundreds of matches — each dumps that volume into the parent’s window even while it’s still working, slowing every subsequent turn and crowding out the actual task.

core-agent ships three mechanisms — designed together, deployed independently — to keep long sessions alive. All three are on by default. See docs/context-management-design.md for the full design rationale.

Skills

Mon, 01 Jan 0001 00:00:00 +0000

core-agent loads SKILL.md bundles from .agents/skills/<name>/. The schema mirrors Anthropic’s published skills format so existing skill bundles drop in directly.

Directory layout

.agents/
└── skills/
 ├── echo/
 │ └── SKILL.md
 ├── jira-triage/
 │ ├── SKILL.md
 │ └── examples/
 │ └── ticket.md
 └── data-export/
 ├── SKILL.md
 └── helpers/
 └── export.py

Each subdirectory of .agents/skills/ is one skill. A skill must contain a SKILL.md at its root; the directory name is the skill’s identifier (and what the agent invokes by). Other files in the directory are referenced from SKILL.md and loaded on demand.

Permissions

Mon, 01 Jan 0001 00:00:00 +0000

The permission gate is the central chokepoint consulted before every tool call. It enforces three things in order:

A built-in bash denylist that’s non-overridable (even yolo mode can’t run rm -rf /).
A path scope check for file tools — out-of-scope reads/writes either prompt the user or fail.
The mode + allow/deny patterns from .agents/config.json.

Modes

Mode	Behavior
`ask` (default)	Allowlisted calls pass automatically; everything else prompts the user via the configured `Prompter`. With no `Prompter`, prompts fail closed with a clear error.
`allow`	Only allowlisted calls pass. Everything else is rejected without prompting — useful for headless / automated runs.
`yolo`	All calls pass except those caught by the bash denylist or a deny-pattern. Use with care; intended for trusted local dev.

Set via .agents/config.json:

Attach TUI

Mon, 01 Jan 0001 00:00:00 +0000

core-agent-tui is the operator-facing terminal UI for attach-mode — the remote client for an agent running elsewhere (workstation, K8s pod, peer-registered fleet member). It ships as a separate binary so the default core-agent stays distroless-clean (no terminal-rendering deps land in production K8s images). See Configuration → attach for the listener-side config and the HTTP/SSE protocol it consumes.

For local interactive use, run core-agent directly — its in-process TUI is the default when stdin is a terminal. core-agent-tui is the remote client only.

Library API

Mon, 01 Jan 0001 00:00:00 +0000

core-agent is designed to be embedded as a Go library. The bundled cmd/core-agent is a thin reference wrapper; production consumers will typically write their own binary that composes these packages.

Package overview

Import path	Purpose
`github.com/go-steer/core-agent/agent`	Multi-turn agent wrapping ADK’s `llmagent + runner`.
`github.com/go-steer/core-agent/instruction`	`AGENTS.md` / `CLAUDE.md` / `GEMINI.md` fallback loader.
`github.com/go-steer/core-agent/config`	`.agents/config.json` schema, discovery, atomic persist.
`github.com/go-steer/core-agent/permissions`	Ask / allow / yolo gate; bash denylist; path scope.
`github.com/go-steer/core-agent/tools`	`GateToolset` wrapper bridging permissions to ADK toolsets.
`github.com/go-steer/core-agent/mcp`	MCP server lifecycle from `.agents/mcp.json`.
`github.com/go-steer/core-agent/skills`	`SKILL.md` discovery → ADK `skilltoolset`.
`github.com/go-steer/core-agent/models`	`Provider` interface + registry / `Resolve()`.
`github.com/go-steer/core-agent/pkg/models/gemini`	Gemini API + Vertex AI provider.
`github.com/go-steer/core-agent/pkg/models/anthropic`	Anthropic / Claude provider (first-party + Vertex).
`github.com/go-steer/core-agent/telemetry`	OpenTelemetry exporter setup.
`github.com/go-steer/core-agent/usage`	Per-turn token + cost tracker.
`github.com/go-steer/core-agent/session`	Transcript persistence (`.agents/sessions/`).
`github.com/go-steer/core-agent/runner`	Headless (one-shot) + REPL (multi-turn) drivers.

Minimal example

The shortest possible program: pick a Gemini model, run one turn, print partial text:

Agent card

Mon, 01 Jan 0001 00:00:00 +0000

core-agent can publish a /.well-known/agent-card.json descriptor from its attach-mode listener so external discovery systems — most notably Google Cloud Agent Registry — can index the binary’s name, description, and skills without a parallel registration channel. The endpoint is opt-in: a binary built without the card config behaves exactly like today’s binary plus a card-shaped 404 at the well-known path.

The card is discovery metadata, not a transport promise. core-agent does not speak the A2A JSON-RPC transport — the url field on the card points at the attach listener, and an A2A client that POSTs JSON-RPC at it gets a 404. GCP Agent Registry, the actual consumer of this endpoint, only reads the card; it never drives the URL as A2A. If you need a non-A2A-shaped registration, GCP also supports NO_SPEC which doesn’t require a card at all — see the Agent Registry register-agents docs.

Autonomous runs

Mon, 01 Jan 0001 00:00:00 +0000

agent.RunAutonomous is the multi-turn driver for unattended workers — batch jobs, CI tasks, scheduled scripts, anything that needs to keep working after a single agent.Run turn would have ended. It loops agent.Run against a goal, enforces run-level budgets, and stops when the model signals “done” via an internal lifecycle tool.

Two senses of “autonomous” matter here:

Sense	Driver	When to reach for it
Within one turn	`agent.Run` already loops the model through tool-call cycles until a final response	Single self-contained tasks: “find every TODO in the repo and write a list”
Across turns	`agent.RunAutonomous` loops `agent.Run` against a goal	Long-running work the model decomposes into multiple turns

This page covers across-turn autonomy. For the within-turn case, see Library API → Streaming events.

Web UI (--ui flag)

Mon, 01 Jan 0001 00:00:00 +0000

The --ui flag mounts the mast-web operator UI at /ui/* on the attach listener. One binary, one port, one auth boundary — the SPA shares the same TLS cert, bearer token, and CORS origin as the attach API endpoints, eliminating cross-origin configuration entirely. The agent serves the UI; no separate web server required.

This is one of four ways to deploy mast-web. The others (hosted SPA, container image, self-host tarball) live in go-steer/mast-web and don’t involve core-agent at all. Pick --ui when you want a single binary, an air-gapped deployment, or local-dev iteration.

Sessions and event log

Mon, 01 Jan 0001 00:00:00 +0000

By default, every agent.Agent uses ADK’s in-memory session service: conversation history is alive only for the process lifetime, and a crash loses everything. For audit logs, replay, crash-resume, or any cross-restart workflow, wire a durable backend via the eventlog package.

This page covers when to use durable sessions, how to enable them, and what the substrate gives you.

What you get

import (
 "github.com/glebarez/sqlite"
 "github.com/go-steer/core-agent/pkg/agent"
 "github.com/go-steer/core-agent/pkg/eventlog"
)

handle, err := eventlog.Open(ctx, sqlite.Open("sessions.db"))
if err != nil { /* ... */ }
defer handle.Close()

a, _ := agent.New(m,
 agent.WithEventLog(handle),
 agent.WithTools(myTools),
)

The *eventlog.Handle bundles two things every consumer wants:

Scion adapter

Mon, 01 Jan 0001 00:00:00 +0000

extras/scion-agent/ packages core-agent for Scion’s container runtime. It is the Go counterpart of Scion’s Python adk_scion_agent example — same lifecycle contract, built on the core-agent library.

The adapter is opt-in. The core library and bundled CLI work standalone; you only build scion-agent when you want to deploy core-agent as a Scion-managed agent.

What it adds on top of `core-agent`

--input <task> flag. Scion’s harness appends this when starting an agent with an initial task. From v1.3.0 the value is pushed onto the agent’s inbox via Agent.Inject before the main loop starts; the first turn then drains it as the first [Inbox] block.
Non-blocking inbox loop (v1.3.0+). A background goroutine reads stdin and pushes each line onto the agent’s inbox via Agent.Inject. The main loop waits on Agent.InboxArrived() and runs a turn with prompt "continue"; the per-turn drain prepends queued messages as an [Inbox] block. Messages arriving while a turn is in flight no longer block — they queue immediately and land on the next turn’s prompt. (Previously the binary scanned stdin between turns, so a 30-second tool call delayed every message by 30 seconds.)
Transient activity emission. On every agent / tool boundary the adapter writes thinking, executing, or working to $HOME/agent-info.json so Scion’s UI can render what’s happening live.
Sticky lifecycle states via a sciontool_status tool. The model invokes this tool to declare ask_user, blocked, task_completed, or limits_exceeded. The tool shells out to Scion’s sciontool binary so the hub gets notified.

Outside a Scion container (no sciontool on PATH, no writable $HOME) the lifecycle hooks degrade to no-ops, so the same binary is usable for local development.

Multi-session daemon

Mon, 01 Jan 0001 00:00:00 +0000

One core-agent daemon serves multiple concurrent sessions belonging to different users — each with its own identity, ACL, permission grants, instruction overlays, and audit attribution. Multi-session is opt-in and strictly backward-compatible: deployments that don’t enable it see identical single-user behavior.

This page covers when to turn it on, how to configure it, and what isolation guarantees the substrate gives you. Design background: docs/multi-session-design.md in the repo.

When to use it

The single-user “one process per user per pod” model is fine for personal interactive sessions and per-tenant pod-per-user K8s deployments. Reach for multi-session when one or more of these is true:

core-agent

Autonomous quickstart

What “autonomous” means here

cli-setup skill

What it covers

Triggers

Interactive quickstart

What you’ll have at the end

System instructions

autonomous-setup skill

What it covers

Getting started

Install

As a CLI (Go toolchain)

As a pre-built binary (no Go toolchain needed)

Skills

Workflows

Workflow 1 — Go code reviewer with MCP-backed web search

GKE multi-agent scenario

library-embedding skill

What it covers

Providers

Auto-detection

Slash reference

Quick reference

Session control

Status + observability

Context management

Subagents and wrappers

Why core-agent

Configuration

The .agents/ directory

Cost efficiency

The cost hierarchy

Built-in tools

The built-in catalog

Library guide

Who this is for

MCP servers

mcp.json schema

ServerSpec

Context management

Skills

Directory layout

Permissions

Modes

Attach TUI

Library API

Package overview

Minimal example

Agent card

Autonomous runs

Web UI (--ui flag)

Sessions and event log

What you get

Scion adapter

What it adds on top of core-agent

Multi-session daemon

When to use it

The `.agents/` directory

`mcp.json` schema

`ServerSpec`

What it adds on top of `core-agent`