Harness

The harness is the agent runtime around the language model. It runs on the customer premises as the llm-microlink microservice, next to LogMan.io and the sandboxes.

The harness owns:

• Conversation lifecycle and streaming to the UI — see Conversations
• Tool discovery, activation, and execution
• Skill loading from the Library
• Sandbox containers and share mounts
• Human-in-the-loop controls (chat, vetting, autonomy)
• Slash commands
• Audit recording of conversations and executed actions

The model proposes; the harness decides what actually runs.

Conversations

Interactive chat runs in conversations: streaming sessions between users, the model, and tools. See Conversations for multiplayer visibility, context window management, renaming, and the web UI.

Tools

Tools are the model’s hands. A small core set is always loaded for a conversation; other built-in tools are discovered by name and activated on demand with activate_tool.

Built-in tools

Tool	Purpose
activate_tool	Load the full schema of an optional tool (or an MCP server tool) into the conversation
ask	Ask the user one to three multiple-choice questions and wait for answers
web_fetch	Fetch a public HTTP(S) page into context (headless browser path)
library_list	List items under a Library path
library_read	Read Library content into the model context (skills, prompts, Soul, references)
library_write	Create or update a Library item (activate first if not loaded)
library_delete	Delete a Library item (activate first if not loaded)
delegate	Spawn a subagent in an isolated conversation; use silent: true for handoff to a fresh context window on the same sandbox
schedule	Create a delayed or recurring job
shell_exec	Run a bash command in the sandbox
read_file	Read a file from the sandbox workspace (or via /library/…)
write_file	Write a file under the sandbox workspace
share_search	Semantic or full-text search over an indexed share
notify	Send a notification through configured channels
ping	ICMP reachability check (preferred over sandbox ping)

Optional tool sources

Beyond the built-in catalogue:

• MCP servers configured on the microservice (activate the server alias, then a concrete tool name)
• Tools advertised in the cluster (ZooKeeper)

Use only tools the harness exposes for that conversation. Invented tool names are rejected.

Sandbox

The sandbox is a dedicated Linux container for agent work on the customer premises.

Properties:

• The container filesystem is read-only except for writable mounts
• Task-local storage is /workspace (working directory for shell_exec)
• The LogMan.io Library is available read-only at /library (FUSE mount via asab-library)
• Shares bind-mount at /workspace/<share-id> when attached
• Home for the container user is under /home/ai
• Common tooling is preinstalled (Python 3, DuckDB, curl, wget, jq, yq, git, OpenSSH client, dig, …)

The model never gets a free shell on the LogMan.io host. All execution goes through harness tools into this container. Operators browse produced files on the Sandboxes screens in the UI.

Typical flow: write scripts or outputs under /workspace, run them with shell_exec, keep durable material in a share or in the Library.

Shares and mounts

Three storage ideas meet inside the sandbox:

Store	Mount in sandbox	Lifetime	Typical content
Workspace	/workspace	Conversation / sandbox	Drafts, downloads, intermediate files
Shares	/workspace/<share-id> (for example /workspace/facts, /workspace/lmio, /workspace/lmio-kb)	Survive conversations	Facts, instance credentials, knowledge bases
Library	/library (Library path /X → /library/X)	Product / tenant Library layers	Prompts, skills, Soul, declarations

Share mounts are usually attached automatically from skill frontmatter (shares:) or via the /share command. The same share can be mounted into many conversations. Users can browse shares from the Shares UI even when no conversation is active.

Soul (/AI/Soul/SOUL.md in the Library) holds personality. Durable operational truths go to the facts share (/workspace/facts when mounted), not into Soul.

Commands

Slash-style commands are harness controls (not LLM tools). Examples:

• /goal — set a persistent goal the harness uses to judge progress
• /summarize — generate a short conversation title
• /share — attach or manage shares
• /hitl — deliver human-in-the-loop responses
• Final-answer gating — for some models, a small judge scores whether the last reply is finished; if not, the harness nudges the agent to continue

Human-in-the-loop and control

Operator control is a core differentiator of the LogMan.io harness compared with ad-hoc “LLM + scripts” setups.

You choose how much of a human stays in the loop — and you can combine modes in one deployment or even one workflow:

Mode	What happens
Chat	A user steers the agent turn by turn; the agent can also call ask when a missing parameter would change the outcome
Vetting	Policy marks sensitive tool calls (for example risky shell_exec patterns). The harness pauses, the operator approves or declines, then execution continues or stops
Fully autonomous	Agents and schedules run toward a goal with little or no interactive chat
Mixed	Chat for planning, autonomy for bulk work, vetting only on high-impact actions

If the operator declines a vetted call, the tool returns a clear refusal (“User declined this tool call.”). The model must not bypass that gate — it is a hard stop enforced by the harness, not by prompt wording alone.

Stop, resume, model choice, and tool/skill visibility in the UI give further operational control.

Audit log

The harness keeps an audit trail of what the AI did:

• Conversations and every timeline item (user messages, assistant text, reasoning, tool calls, engine notices) are stored in the harness database
• Each tool execution is recorded with name, arguments, result or error, and status — including vetting outcomes
• Optional LLM traces capture wire-level request/response traffic for support and evaluation (with retention controls)

That trail supports compliance reviews, incident follow-up (“what did the agent change?”), and quality tuning. Autonomy does not mean invisibility: the same recording applies to interactive chats, agents, and scheduled runs.

In the web application

Screen overview: AI in the web application. Conversation detail (toasts, alerts, token indicator): Conversations.