Giving the agent context
These are the built-in ways to feed the agent. Need a tool or integration that doesn't exist yet? The agent can build it into Cial — see Extending Cial.
The agent only knows what you give it. Four mechanisms feed a turn, and they split along two axes: reference you attach vs. actions you trigger, and per-message vs. persistent. Pick by what the moment needs.
Knowledges
A Knowledge is a named, reusable library of context. Each holds instructions
(a short router telling the agent what's inside and when to use it) plus a set of
files (the actual detail — reference docs, examples, conventions). Attach one
with an @-mention and the agent gets the instructions and a file listing for the
turn, then opens individual files only as the task needs them — so large reference
material never crowds the conversation.
Manage them under Settings → Discovery (the feature toggle) and in your Knowledges list. Keep each one scoped to a single topic or project; several small, well-named Knowledges are easier to mention selectively than one catch-all.
Write the instructions as a router, not a copy of the files:
This knowledge covers our frontend conventions.
- Component patterns and naming → components.md
- How we structure state → state-management.md
- Accepted libraries and why → dependencies.md
Using one: type @ in the composer, pick the Knowledge, send. Mention several
when a task spans topics — but only the relevant ones, to keep the agent focused.
The agent always reads the current file contents, so update files as standards
change and prune stale ones (stale context misleads as easily as it helps).
A built-in Knowledge describing the app is always present — it's what lets the agent self-edit. See Self-editing.
Uploads
When the fastest context is the file itself, attach it to a message. Use the composer's attachment control, describe what you want done with it in the same message ("summarize this doc", "fix the bug in this log"), and send. The agent reads the attached files for that turn alongside everything else you've given it — a good fit for documents to summarize, logs to diagnose, or reference to follow.
Attachments are scoped to the message they ride on: to reuse a file later, attach it again. Single uploads have a max size; trim or excerpt very large content. Uploads are on by default; toggle them under Settings → Discovery.
Tools and the vault
The vault is the agent's capability store. Each entry is a tool you define once and then enable per session — nothing is globally live. Two rules drive it:
- Storage is decoupled from exposure. Defining a tool persists it; enabling it on a session is a separate, per-session decision.
- Exposure resolves per turn. Each turn compiles the session's enabled tools into the engine's config on the spot — the session sees exactly what you granted it and nothing else. Changing grants takes effect next turn, with no deploy step.
Manage everything under Settings → Tools.
The three tool types
The name you give a tool is load-bearing: for env_var it's the environment variable
the agent reads, it's the handle in the callable-tools list, and it's how you'll
recognize the tool when enabling it on a session.
Calling an env_var tool returns the raw secret into the session transcript. The
environment merge alone never surfaces the value — only the call does. Anything the
agent reads into a conversation is visible to everyone you share that session with.
env_var is also how some engines authenticate: Kimi Code has no separate
credential — it reads a KIMI_API_KEY from an env_var tool merged into the turn
environment. Adding that key to the vault is what lets Kimi run.
How a turn resolves tools
The vault is inert until a turn runs. The server resolves that session's enabled
tools — never your whole vault — into the engine's config along two surfaces: mcp
servers pass through natively (Claude --mcp-config, Kimi --mcp), while env_var
and md tools are exposed by a bundled vault MCP server named cial. Separately,
every env_var value is also merged into the turn environment.
Scope, masking, and self-management
Secret values are masked wherever tools are listed — you see the name and that a value exists, never the value. The real value is materialized only at turn-resolution time, into the engine's config.
The agent can also manage the vault from inside a turn via Cial's API, but the
access is scoped to a snapshot of that turn's enabled tools — it can act on what
it was granted, not the whole vault. One deliberate exception: a tool the agent
creates mid-turn joins the live snapshot immediately, so it can create an md
snippet and call it within the same turn.
If the agent can't reach something you expected, check in order: the tool exists under Settings → Tools, and it's enabled for that session. A defined-but-not-enabled tool is invisible to the conversation.
Skills and slash commands
A skill is a saved, reusable set of instructions for a particular kind of task; a
slash command is the / shortcut that invokes one. Both work the same from your
side: type / in the composer, filter by name, pick one, add any extra detail, and
send — the agent runs the turn with those instructions attached.
The autocomplete unifies skills scoped to the current project with ones available across all your work, sorted and de-duplicated into one list. It mirrors what the agent can actually run (if it's in the dropdown, the agent can use it) and stays in sync within seconds as skills are added or changed — no restart needed.
Skills vs. Knowledges — both give context, for different moments:
- Skills / slash commands are actions you trigger — kick off a known,
repeatable task with
/. - Knowledges are reference you attach — background the agent reads on demand while it works.