The Agent Platform

An agent, in the classic definition, is anything that perceives its environment and acts upon it (Russell and Norvig, Artificial Intelligence: A Modern Approach). Applied to language models, the industry has converged on a sharper operational form: an agent is an LLM that dynamically directs its own process and tool usage, deciding at each step what to do next, as opposed to a workflow, where code orchestrates the model through predefined paths (Anthropic, Building Effective Agents). Both patterns are legitimate; the IDP pipeline is a workflow, and this category is about the other kind. On this server an agent is a concrete, named thing: a model in a loop, equipped with tools it decides to call, skills that shape how it works, and memory that persists across conversations, all served over the same chat API everything else uses.

1The loop, stated precisely#

Every agentic exchange on this server is the same cycle: the model reads the conversation, REASONS about what it needs, optionally ACTS by calling a tool, OBSERVES the result appended to the transcript, and repeats until it can answer. This reason-act-observe cycle is the ReAct pattern (Yao et al., 2022), and it is what separates an agent from a chatbot: the model's output is not always the answer, sometimes it is a decision to go find out. The loop is bounded (max_tool_calls caps a confused agent), observable (every tool call streams as an event and lands in the result's tool_events), and governed (a tool the operator has not enabled is refused and the refusal is narrated, never silently skipped).

2The named agent: a bundle, not a cage#

agent on any chat request adopts a server-defined agent definition: a reusable bundle carrying a system prompt, a pinned skill, a tool set, a memory intent with its store, a model pin, a reasoning effort, a greeting, and a tool-call budget. Two properties make the mechanism sound:

• The bundle supplies defaults; explicit request fields win. An agent narrows nothing: it saves every caller from restating the same setup, without taking any capability away.
• Unknown names refuse loudly. A typo in agent is a named error, not a silent fallback to vanilla behavior.

Agents are defined once by the operator (Admin Console, Agents section) and discovered by clients at GET /lmkit/v1/agents, so a UI can offer "talk to the support agent" without out-of-band knowledge. The same agent field rides the OpenAI-compatible endpoint as an extension, which means any existing OpenAI-SDK application can adopt a server agent by adding one field. Building and Testing Agents walks the whole lifecycle.

3The four capabilities, and where each lives#

Each is independently useful (a plain request can pin a skill or bring tools without any agent), and the bundle is how they compose into something a team can share.

4Real workloads, mapped#

• The support assistant: a system prompt with the product's voice, a skill carrying the triage procedure, web_search plus the document tools, and memory per customer id, so the third conversation does not restart from zero.
• The operations copilot: connectors expose your internal systems over MCP; the agent reasons over live data with the loop bounded and every call logged.
• The document analyst: the server's own document engine rides as tools (the same catalog its MCP endpoint serves), so "compare these two contracts and extract the differences" is an agent turn, not a bespoke pipeline.
• The research assistant: web search under the egress policy, summarization at the end, memory keyed by project.

When the task is fixed and repeatable, prefer the workflow: the IDP endpoints exist so you do not need an agent to split a mailroom batch. Agents earn their cost where the path genuinely cannot be predefined, which is the honest version of the industry advice to use the simplest pattern that works (Anthropic).

5Local changes what agents are allowed to do#

Every capability above runs on hardware you control: tool results, memory facts, skill contents, and reasoning traces never leave the machine. That is not a compliance footnote; it changes the design space, because an agent that may read real documents and remember real customers is exactly the agent most organizations cannot send to a third-party API. The governance surfaces (tool policy, egress modes, skill allowlists, memory administration) are each covered in their chapter.

6Stated plainly#

• An agent is a model directing its own loop; a workflow is code directing the model. This server implements both, and this category is the agent half.
• The named agent is a bundle of defaults (prompt, skill, tools, memory, model), adopted by one field on any chat endpoint, overridable per request, discoverable by API.
• Tools, skills, and memory are the capability triad; each has its own chapter, its own governance, and its own chapter of the admin console.