<!-- GENERATED by ops/tools/skill-sync — do not edit by hand. Run pnpm skills:sync. -->

Leviathan & AI — what you can do

/admin/d/ai · pillar ai

Program the agent - personas, reasoning maps, the tools it may call, MCP servers and skills.

Fetch this, never remember it

These change per install and per release. Call for them - a list written here would be a future lie.

How to actually do things here

Written by hand, because the order and the traps are the part no file can derive.

Create a chatbot the user can talk to

1. Personalities. list_personas for what exists, select_persona to open one.
2. set_persona_field writes the name and system prompt; set_provider chooses the model lane.
3. bind_toolbank gives it server tools; bind_map attaches the rules it must follow.
4. save_persona persists - it is the only tool on this page that writes.

Trap: The per-persona tool policy (capabilities: {mode, tools}) is enforced SERVER-side when the turn runs, never in the widget - the widget is what builds the list it sends, so a widget filtering its own list is worth nothing. mode:"all", an unknown mode, and no policy at all are all identity.

Give the agent a tool it does not have yet

1. Check first: every adapter this install loaded is ALREADY a callable tool. GET /api/adapters/tools - if the name is there, skip to the last step.
2. Otherwise Function Calls: write the CONTRACT (name, description, and a JSON-Schema parameters) and the BINDING (executor: {kind, ref, config}).
3. Test it in place before wiring it anywhere.
4. Toolbanks: group the names into a bank. Personalities: bind_toolbank. A bot holds NAMES, not definitions.

Trap: [critical] Not every executor kind binds in every host. A chatbot lane injects the adapter, action, grid-cell and integration runners ONLY - so mcp-tool, module-export and fabric bind to null for a bot and the tool silently does nothing, while the same row works from a workflow. Check where it will run before choosing a kind.

Stop the agent doing something

1. Persona-wide: set the capability policy on the bot (allow or deny with a list of tool names).
2. Rule-wide: Reasoning Maps. add_rules with a text and a why, so the model can apply the rule instead of pattern-matching it.
3. A map can also narrow the toolbox with its own tool policy, which applies to server tools too.
4. save_map, then read_compiled_map to see exactly what the model will be told.

Trap: Maps are injected AFTER the persona, so a rule can override a habit the persona described. Screen-bound maps fail CLOSED without a read check - the maps collection is member-writable, which makes it the prompt-injection lane.

Run a coding agent on the user's own project

1. Register the project first: POST /api/projects with {name, kind}. A sandbox project is scaffolded for them; a local folder needs an explicit path and is refused outright on a hosted install.
2. Pick a provider that can actually use tools. Ask GET /api/providers rather than assuming.
3. POST /api/coding/runs with {message, projectId, provider}. It answers 202 with a run id and never blocks.
4. Follow it on GET /api/coding/runs/:id/stream, or read it later under Runs.

Trap: [critical] A provider without tool support answers in prose and writes NO FILES, which reads exactly like a model that chose not to act. Shell access is off by default on a local project and must be turned on per project. A run with no key answers 402 - buy or bring one.

Let an app the user is building call Leumas capabilities

1. The app declares what it needs: permissions: ["adapters:<system>.<fn>"] on its defineLeumasApp.
2. The operator grants it at install. The facade then exposes EXACTLY those functions and nothing else.
3. A sandboxed app calls out through the plugin proxy; a first-party one gets the facade directly.
4. The reverse direction is free: an app's own actions become adapter functions, functioncalls and MCP tools from the same declaration.

Trap: An ungranted capability is ABSENT from the context object, not refused - so the failure looks like "undefined is not a function", not like a permission error. That is deliberate: it stops an app probing what an operator holds.

Tabs

Every one is a real URL. A tab with its own section below carries a real job.

Tabs in focus

personalities - Personalities

Who answers - provider, model, prompt, voice, tools, memory and the capability policy, one row per persona.

Read with: list_personas | get_persona | list_catalogs

Write with: select_persona | set_persona_field | set_provider | bind_toolbank | bind_map | save_persona

1. list_personas, then select_persona - everything else edits the selected draft.
2. Set fields, provider, toolbanks and maps in any order.
3. save_persona.

Trap: Only save_persona writes; every other tool moves a draft. Create and delete are deliberately absent from the tool set - they are the operator's.

reasoning-maps - Reasoning Maps

The rule-sets a persona thinks with, and which surfaces each applies on.

Read with: get_map_overview | list_rules | read_compiled_map | list_known_surfaces

Write with: add_rules | set_rule | remove_rule | set_map_surfaces | set_tool_policy | save_map

1. get_map_overview, then list_rules - never edit a map you have not read.
2. add_rules; give each a why, which is what lets a model apply it rather than match it.
3. set_map_surfaces to bind it to screens; set_tool_policy to narrow the toolbox with it.
4. save_map, then read_compiled_map to see the actual text.

Trap: A map bound to a surface is dropped entirely when no read check is supplied. That is fail-closed on purpose.

functioncalls - Function Calls

Every tool that can be called, its argument contract, and what actually executes it.

Read with: GET /api/adapters/tools

Trap: [critical] The schema key is parameters. input, inputSchema, schema and args are dropped on the way to the model, which then sees a tool it cannot pass anything to - and every guard still passes.

functioncalls/capabilities - Function Calls → Capabilities

What is registered LIVE right now versus what has merely been seen this session, plus the per-persona policy.

Read with: list_catalogs

Write with: add_rule

Trap: The live registry is EPHEMERAL by design - a page registers its tools on mount and removes them on unmount, which is correct, because a tool that edits a reasoning map must not be callable from the billing screen. Nothing is persisted, so a stale row reads exactly like a live one.

toolbanks - Toolbanks

Named groups of functioncalls, so a persona is handed a set rather than a list.

Trap: A bank holds tool NAMES. Renaming a functioncall leaves every bank pointing at nothing, with no error.

mcp - MCP Servers

Publish a selection of tools outward as a hosted MCP server that other agents can call.

Read with: GET /mcp/hosted

Trap: A hosted server IS an Imperium site with a callable mode, so it is authored in the site editor, not here. This tab reads what exists.

skills - Skills

Saved procedures an agent follows when a task matches.

Read with: GET /api/skills

Trap: Two sources share this page. Yours are editable; the built-in ones are derived from domains and installed apps, are rebuilt on every restart, and can only be switched off.

inventor - Inventor

One sentence to a manufacturable product - enclosure, board and firmware, cross-checked against each other.

Trap: Every stage here is an adapter call rather than a REST route, so the tool name is the API.

flux - Flux — Hardware

The hardware workspace - circuit boards and firmware sketches, as projects.

Read with: GET /api/projects

Write with: POST /api/projects

Trap: FLUX is a GALLERY, not an editor - it deliberately owns none, because Circuit Studio and the Arduino IDE already exist. Agent work on one runs through the coding-run lane with a hardware mode, not through this page.

codex - Codex — Code

The coding agent, pointed at the user's own projects.

Read with: GET /api/projects | GET /api/coding/conversations

Write with: POST /api/projects | POST /api/coding/runs

1. Register or pick a project. Sandbox projects are scaffolded; local ones need a path and the file capability.
2. Choose a provider that can use tools - check, do not assume.
3. POST /api/coding/runs returns 202 immediately; follow the stream.

Trap: [critical] Two providers answer without being able to touch a file. If files were meant to change and none did, check the provider before debugging the prompt. A run carries the project MEMORY first, so what is written there shapes every run in that project.

runs - Agent Runs

What an agent actually did - runs, their events and their cost.

Read with: GET /api/coding/runs

runs/local - Agent Runs → Local chats

Chat transcripts read off this machine rather than the server.

Trap: Machine-local and admin-only. On a hosted install it is simply not there, which is not a fault.

Ways in

Declared cross-links. Every address is matched against the real route table by check:huds.

Tools an agent can call here

These are live page capabilities: they exist only while that surface is open, and they call the page's own mutators, so a change made through one is a change the operator can see. A tool missing from this list is not callable — reach for the API or an adapter instead.

ai:hud — AI console: …

Source: ai/hud/model/useAiHudCapabilities.js

What the page tells an agent about itself:

The user is on the AI console — a heads-up display over a live view of their own AI: a swipeable deck of every persona they own, the one they picked answering in the composer, and the section's tabs in the left rail. This section is the AGENT: personas, reasoning maps, functioncalls, toolbanks, the project agents and MCP. Triggers, actions, workflows, macros and the function index live in the DYNAMIC section (/admin/dynamic/...) — send the user there for those rather than looking for a tab here. What a bot can CALL is unaffected by that split; it is only where they are managed that differs. The persona you are editing may be the persona you ARE. Always call get_persona before reasoning about or changing anything, and say which persona you are changing when it is not the one talking. TWO LANES, do not confuse them: select_persona, set_persona_field, set_provider, bind_toolbank, bind_map and open_dial_panel change the DRAFT and persist nothing; save_persona is the only tool that writes. Make all your edits, then save once at the end. Never report work as done before save_persona has returned ok. A persona with no provider key answers every turn with the user's own message echoed back. That is the single most common "it does not work", it is invisible unless you look, and list_catalogs is where you look. Temperature and maxTokens are honoured only by the providers in samplingProviders. Setting them for any other provider is a promise the turn quietly breaks — say so rather than setting them. Use open_dial_panel to put what you are discussing in front of the user before you change it. Changing four fields in panels they never saw open is correct and unreadable. You cannot create or delete personas from here, by design. Point the user at Programmable Personality for either.

ai:map-editor — Reasoning map: …

Source: ai/model/useMapCapabilities.js

What the page tells an agent about itself:

The user is editing a REASONING MAP — a compact rule-set that an AI agent must comply with while doing a specific job. Each rule has a kind (must/never/prefer/context), one imperative sentence, and a reason. The reason is not decoration: a rule without one is followed literally and cannot be generalised from. Always call get_map_overview before reasoning about or changing the map — it carries the rule-kind vocabulary and any warnings. TWO LANES, do not confuse them: add_rules, set_rule, remove_rule, move_rule and set_map_meta change the DRAFT and persist nothing; save_map is the only tool that writes. Make all your edits, then save once at the end. Never report work as done before save_map has returned. Prefer few strong rules to many weak ones — a map is loaded for one task and costs every turn that uses it. Order matters: what must never be broken goes first. A map can also be BOUND TO SCREENS (set_map_surfaces): bound that way it is loaded for any turn taken while that screen is open, which is how a page gives you the rules for the thing on it. Binding is a real change to how the assistant behaves everywhere that screen is used — propose it and let the user decide rather than doing it unasked. The editor is a heads-up display: the map is drawn full-screen behind panels the user can close. Use open_map_panel and select_rule to put what you are discussing in front of them. A map does THREE things for a bot that carries hundreds of functioncalls, and they are separate: rules say what to do; set_rule_tools names the functions a rule routes to, which is guidance the agent reads while choosing; set_tool_policy narrows the offer itself so the model is never told about the rest. Reach for the third when a bot has too many tools to choose well among — that is the problem this exists to solve. link_rules records ORDER and DEPENDENCY between rules, which no amount of wording conveys on its own. A rule-set of more than about six rules almost always has some, and an agent given none has to guess.

ai:map-editor — Reasoning map editor

Source: ai/pages/CapabilityRegistry.jsx

What the page tells an agent about itself:

Eight tools change the draft; only save_map writes.

Traps

CRUD is /db/<collection> (chatbots, functioncalls, toolbanks, reasoning_maps, skills, projects); the VERBS are /api/<thing> (/api/coding/runs, /api/adapters/:system/:fn, /leviathan/chat). {kind, ref, config} is the one dispatch descriptor for everything callable, and an unbindable kind resolves to null rather than throwing - which is why a row can look saved and do nothing. Argument merging differs by kind and in opposite directions: an action merges its config AFTER the caller args (config wins), an integration merges its config BEFORE (caller wins). Every crossing into user code or another machine is a facade, not a token: apps get a capability object, sandboxed plugins get a fixed dispatch table, connected software goes through one pipeline, and hardware takes typed verbs - never a command line.