# Agentik {OS} > Agentik {OS} builds AI operating systems: teams of specialized AI agents with shared memory, approvals, and skills that companies install in Claude, Claude Code, Cursor, ChatGPT, Codex, or Hermes through the Model Context Protocol. The operative system runs on the host you already pay. Agentik never buys your tokens. ## What Agentik {OS} is, in one paragraph Agentik {OS} is an AI operating system: a compiled team of specialized AI agents with shared memory, skills, objects and a human approval gate, installed on an MCP host the company already pays for (Claude, Claude Code, Cursor, ChatGPT, Codex or Hermes). It is not a chatbot, not a model, and not a desktop operating system. The host runs the model and pays for the tokens; Agentik never buys tokens. A member talks to an OS with one MCP tool call, `talk`, and one OS can hold separate projects for separate clients. Who it is for: a founder or a team that already pays for an AI host and wants the work organized (a brief, a memory, a gate) instead of another chat window. Priced from $19.99 once for one OS, or $19 a month for three. Words we use, defined once: - Operative system: our own name for an AI operating system. Same thing, our signature. - Host: the app that runs the model and calls Agentik over MCP. Claude, Claude Code, Cursor, ChatGPT, Codex or Hermes. - Director: the lead agent of an OS. It holds the mission, delegates to the other agents and stops at the approval gate. - Studio: the place where a member creates or improves their own OS, included with a monthly seat. - OS unlock: a one-time $19.99 purchase of one official OS. It opens the OS; it does not create a cloud store and does not open Studio. - Human gate: nothing is published, sent, or written to a customer record until a named person approves it. The public site is https://agentik-os.com. MCP calls stay on https://mcp.agentik-os.com/api/mcp. Sign-in and the app stay on the MCP host. Official public OS: Content OS, Growth OS, Librarian OS. Only public approved listings appear below. Marketplace prices, in USD: $19.99 lifetime for one official OS (lifetime does not open Studio); $19/month for any three official OS; $99/month for ten; $199/month unlimited. The host pays the model. On demand is priced on the gap we prove, not by the hour or the day. There is no public CAIO retainer. Book a call: https://cal.com/agentik-os/builder-os ## Pages - [Home](https://agentik-os.com/) - [Marketplace](https://agentik-os.com/os) - [What an AI operating system is](https://agentik-os.com/blog/what-is-an-ai-operating-system) - [Services](https://agentik-os.com/services) - [Install](https://agentik-os.com/connect) - [Pricing](https://agentik-os.com/pricing) - [Docs](https://agentik-os.com/docs) - [Articles](https://agentik-os.com/blog) - [Glossary](https://agentik-os.com/glossary) - [Compare](https://agentik-os.com/compare) ## Operating systems - [Content OS](https://agentik-os.com/os/content-os): An editorial system for ideas, briefs, assets, and approvals, then an authorized package, with a human gate before anything leaves the building. - [Growth OS](https://agentik-os.com/os/growth-os): A growth department: brief, audience, offer, campaign, experiment, and independent critique, without publishing or spending for you. - [Librarian OS](https://agentik-os.com/os/librarian-os): A knowledge intelligence layer: discover sources, record access, extract claims with provenance, keep contradictions, teach to a learner, and feed other OS. Never pretend a book was read. ## Glossary - [A/B test](https://agentik-os.com/glossary/a-b-test): An A/B test is an experiment that compares two versions of a system, such as two prompts or models, by exposing different groups of users to each and measuring which performs better on chosen metrics. - [Acceptable use policy](https://agentik-os.com/glossary/acceptable-use-policy): An acceptable use policy is a set of rules defining how an AI service or tool may and may not be used, prohibiting activities such as generating illegal content or attempting to bypass safeguards. - [Accessibility tree](https://agentik-os.com/glossary/accessibility-tree): An accessibility tree is a structured representation of a page or application interface, listing elements with their roles, names and states, which browser and computer-use agents often read instead of raw pixels or HTML. - [Action space](https://agentik-os.com/glossary/action-space): An action space is the full set of actions an agent is allowed to take in its environment, such as the tools it can call, the commands it can run or the interface elements it can click. - [Activation function](https://agentik-os.com/glossary/activation-function): An activation function is a mathematical function applied to a neuron's output that introduces nonlinearity, allowing a neural network to learn complex relationships rather than only straight-line ones. - [Actor model](https://agentik-os.com/glossary/actor-model): The actor model is a concurrency model in which independent actors hold private state and communicate only by sending asynchronous messages, a design often used to run many agents at once. - [Adam](https://agentik-os.com/glossary/adam): Adam is a popular optimization algorithm that adapts the learning rate for each parameter using running averages of past gradients and their squares. It is widely used to train deep neural networks. - [Adapter](https://agentik-os.com/glossary/adapter): An adapter is a small set of trainable layers or weights inserted into or attached to a frozen pretrained model, letting it learn a new task without retraining the full network. - [Adversarial example](https://agentik-os.com/glossary/adversarial-example): An adversarial example is an input deliberately altered, often in ways humans barely notice, to cause an AI model to make a wrong prediction or produce an unintended output. - [Agent communication language](https://agentik-os.com/glossary/agent-communication-language): An agent communication language is a formal language for messages between software agents, defining message types such as request, inform or propose along with their meaning, as in the classic FIPA ACL and KQML standards. - [Agent discovery](https://agentik-os.com/glossary/agent-discovery): Agent discovery is the mechanism by which agents find other agents or services able to perform a task, typically by querying a registry or reading published descriptions of their capabilities. - [Agent environment](https://agentik-os.com/glossary/agent-environment): An agent environment is everything an agent can perceive and act upon, such as a file system, a browser, a set of APIs or a simulated world, which returns observations in response to its actions. - [Agent framework](https://agentik-os.com/glossary/agent-framework): An agent framework is a software library that provides ready-made building blocks for agents, such as model connectors, tool definitions, memory, planning and multi-agent coordination, so developers do not build them from scratch. - [Agent harness](https://agentik-os.com/glossary/agent-harness): An agent harness is the software surrounding a model that turns it into a working agent, handling the loop, tool execution, context management, permissions and state so the model can act over many steps. - [Agent loop](https://agentik-os.com/glossary/agent-loop): An agent loop is the repeating cycle that drives an AI agent: the model decides on an action, the action is executed, the result is fed back, and the cycle continues until a stop condition is reached. - [Agent memory](https://agentik-os.com/glossary/agent-memory): Agent memory is the set of mechanisms that let an AI agent retain and recall information across steps or sessions, such as conversation history, stored facts, user preferences and past outcomes. - [Agent orchestration](https://agentik-os.com/glossary/agent-orchestration): Agent orchestration is the coordination of one or more AI agents, tools and processes so they work together on a larger task, covering who does what, in which order, with which data and under which controls. - [Agent runtime](https://agentik-os.com/glossary/agent-runtime): An agent runtime is the execution environment that hosts running agents, managing their processes, tool access, state, resource limits and communication while they carry out tasks. - [Agent SDK](https://agentik-os.com/glossary/agent-sdk): An agent SDK is a software development kit, usually published by a model provider, that gives developers libraries and APIs for building agents that call tools, manage context and run multi-step tasks. - [Agent skill](https://agentik-os.com/glossary/agent-skill): An agent skill is a packaged set of instructions, scripts and reference files that an agent can load when a task calls for it, giving it specialized know-how without keeping everything in its context. - [Agent state](https://agentik-os.com/glossary/agent-state): Agent state is the information an agent keeps while working on a task, such as the conversation so far, intermediate results, plans and variables, which determines what it knows at each step. - [Agent swarm](https://agentik-os.com/glossary/agent-swarm): An agent swarm is a group of many relatively simple agents that coordinate through local interactions or lightweight handoffs rather than a single central controller, to complete tasks collectively. - [Agent team](https://agentik-os.com/glossary/agent-team): An agent team is a group of AI agents organized to work together on a shared objective, typically with defined roles, communication rules and a way of merging their outputs. - [Agent trajectory](https://agentik-os.com/glossary/agent-trajectory): An agent trajectory is the complete recorded sequence of an agent's reasoning, actions and observations during a task, used for debugging, evaluation and training. - [Agent-computer interface](https://agentik-os.com/glossary/agent-computer-interface): An agent-computer interface is the set of commands, tools and output formats through which a language model agent interacts with a computer, designed around the model's strengths rather than those of a human user. - [Agent2Agent protocol](https://agentik-os.com/glossary/agent2agent-protocol): The Agent2Agent protocol is an open protocol, originally introduced by Google, that lets AI agents built on different frameworks discover each other, exchange messages and collaborate on tasks. - [Agentic AI](https://agentik-os.com/glossary/agentic-ai): Agentic AI is a broad term for AI systems designed to act toward goals with some autonomy, planning steps, using tools and adapting to results, rather than only producing a single response to a prompt. - [Agentic OS](https://agentik-os.com/glossary/agentic-os): An agentic OS is an AI operating system whose agents are allowed to act, and whose memory keeps the constraint after they act. The category name is agentic OS. The product name is Agentik. A person still approves before anything is published, sent, or written to a customer record. - [Agentic RAG](https://agentik-os.com/glossary/agentic-rag): Agentic RAG is a form of retrieval-augmented generation in which an AI agent decides when and what to retrieve, can reformulate queries and choose among sources, and iterates until it has enough information. - [Agentic workflow](https://agentik-os.com/glossary/agentic-workflow): An agentic workflow is a process in which language models do more than answer once, taking several steps that may include planning, tool use, checking results and revising work toward a goal. - [AGENTS.md](https://agentik-os.com/glossary/agents-md): AGENTS.md is an open convention for a Markdown file placed in a code repository that gives coding agents project-specific instructions, such as build commands, test procedures and coding conventions. - [AI accelerator](https://agentik-os.com/glossary/ai-accelerator): An AI accelerator is any specialized hardware designed to speed up machine learning computations, including GPUs, TPUs, NPUs and custom chips, offering better performance or efficiency than general-purpose processors. - [AI agent](https://agentik-os.com/glossary/ai-agent): An AI agent is a worker that can use tools. An operating system is what assigns the work, keeps the memory, and puts a human on the gate. A company that searches for AI agents usually needs the system, not another bot that forgets the last decision. - [AI audit](https://agentik-os.com/glossary/ai-audit): An AI audit is an independent or internal examination of an AI system's design, data, performance and controls to check that it meets legal, ethical and organizational requirements. - [AI coding assistant](https://agentik-os.com/glossary/ai-coding-assistant): An AI coding assistant is a tool that helps programmers write code through suggestions, completions, explanations and chat inside an editor, typically acting on request rather than carrying out long tasks on its own. - [AI copilot](https://agentik-os.com/glossary/ai-copilot): An AI copilot is an assistant embedded in an application that works alongside a person, suggesting content, answering questions and carrying out requested actions while the person stays in control of decisions. - [AI gateway](https://agentik-os.com/glossary/ai-gateway): An AI gateway is a proxy between applications and model providers that centralizes access to multiple models, adding features such as key management, routing, fallbacks, caching, cost tracking and logging. - [AI governance](https://agentik-os.com/glossary/ai-governance): AI governance, here, means a person approves before an agent publishes, sends, or writes to a customer record. Agentik does not publish a legal timetable and does not administer any regulation. A catalog entry is not consent. A compile is not a release. - [AI impact assessment](https://agentik-os.com/glossary/ai-impact-assessment): An AI impact assessment is a structured review carried out before or during deployment to identify how an AI system could affect people's rights, safety and wellbeing, and to plan mitigations. - [AI implementation](https://agentik-os.com/glossary/ai-implementation): AI implementation, here, is the on-demand sequence for one company: audit and brief, connect the tools, map the gap, then a plan and a roadmap. It is not a platform evaluation. The company is paid against the return it can show, not against the clock, and this page is not a quote. - [AI operating system](https://agentik-os.com/glossary/ai-operating-system): An AI operating system is a set of specialized agents, shared memory, approvals, and skills that a company installs on the host it already pays. Agentik is that system. It is not a chatbot, and it is not a PC operating system. The host runs the model. Agentik never buys the tokens. - [AI safety](https://agentik-os.com/glossary/ai-safety): AI safety is the field concerned with preventing AI systems from causing accidental or deliberate harm, covering research on alignment, robustness, misuse prevention, monitoring and the control of increasingly capable models. - [AI watermarking](https://agentik-os.com/glossary/ai-watermarking): AI watermarking is the embedding of a hidden, detectable signal into AI-generated text, images, audio or video so the content can later be identified as machine-generated. - [Air-gapped deployment](https://agentik-os.com/glossary/air-gapped-deployment): An air-gapped deployment is a system physically or logically isolated from the internet and other networks, used for highly sensitive AI workloads where no data may leave the environment. - [Alignment](https://agentik-os.com/glossary/alignment): Alignment is the effort to make AI systems pursue the goals and values their designers and users intend, behaving helpfully and honestly while avoiding harmful or unintended behavior. - [Anonymization](https://agentik-os.com/glossary/anonymization): Anonymization is the irreversible removal or transformation of identifying details in data so individuals can no longer be identified, unlike pseudonymization, which replaces identifiers with codes that can be reversed using separately stored information. - [API gateway](https://agentik-os.com/glossary/api-gateway): An API gateway is a service that sits in front of backend APIs and handles common tasks such as authentication, routing, rate limiting, logging and request transformation in one place. - [API key](https://agentik-os.com/glossary/api-key): An API key is a secret string that identifies and authenticates an application when it calls an API, and it must be stored securely because anyone holding it can use the associated account. - [API rate limit](https://agentik-os.com/glossary/api-rate-limit): An API rate limit is a cap on how many requests or tokens a client can send to a service within a time window, protecting capacity and enforcing fair use, with excess requests typically rejected. - [Approximate nearest neighbor](https://agentik-os.com/glossary/approximate-nearest-neighbor): Approximate nearest neighbor search is a family of algorithms that find vectors very close to a query much faster than exact search, accepting that a few true nearest neighbors may be missed. - [Artificial general intelligence](https://agentik-os.com/glossary/artificial-general-intelligence): Artificial general intelligence is a hypothetical AI system able to understand, learn, and perform nearly any intellectual task a human can, across domains, rather than excelling only at narrow tasks. - [Artificial intelligence](https://agentik-os.com/glossary/artificial-intelligence): Artificial intelligence is the field of computer science focused on building systems that perform tasks usually associated with human intelligence, such as understanding language, recognizing images, reasoning, and making decisions. - [Artificial neuron](https://agentik-os.com/glossary/artificial-neuron): An artificial neuron is the basic unit of a neural network. It multiplies its inputs by weights, adds a bias, and passes the result through an activation function to produce an output. - [Asynchronous execution](https://agentik-os.com/glossary/asynchronous-execution): Asynchronous execution is running a task without making the caller wait for it to finish, so other work can continue and the result is delivered later through a callback, event or status check. - [At-least-once delivery](https://agentik-os.com/glossary/at-least-once-delivery): At-least-once delivery is a messaging guarantee that every message will be delivered one or more times, never lost but possibly duplicated, so consumers should handle messages idempotently. - [Attention mechanism](https://agentik-os.com/glossary/attention-mechanism): An attention mechanism is a neural network component that lets a model weigh how relevant each part of its input is to every other part when building its representation of the data. - [Audit log](https://agentik-os.com/glossary/audit-log): An audit log is a chronological, tamper-resistant record of actions taken in a system, such as who or which agent accessed data, changed settings or triggered operations, used for security reviews and compliance. - [Autoencoder](https://agentik-os.com/glossary/autoencoder): An autoencoder is a neural network trained to compress its input into a smaller representation and then reconstruct the original from it, learning useful features without labels. - [AutoGen](https://agentik-os.com/glossary/autogen): AutoGen is an open-source framework from Microsoft for building multi-agent applications in which several language model agents, tools and humans converse with each other to complete tasks. - [AutoGPT](https://agentik-os.com/glossary/autogpt): AutoGPT is an open-source project that became one of the first widely known autonomous agent experiments, having a GPT model break a user goal into tasks and pursue them in a loop with tools. - [Autonomous agent](https://agentik-os.com/glossary/autonomous-agent): An autonomous agent is an AI system that pursues a goal over multiple steps with little human input, deciding on its own which actions to take, observing the results and adjusting until the task is done or it stops. - [Autonomy level](https://agentik-os.com/glossary/autonomy-level): An autonomy level describes how much an agent may do without human involvement, ranging from only suggesting actions, to acting with approval, to acting independently within defined limits. - [Autoregressive model](https://agentik-os.com/glossary/autoregressive-model): An autoregressive model generates a sequence one element at a time, with each new element predicted from the ones produced before it. Most text-generating language models work this way. - [Autoscaling](https://agentik-os.com/glossary/autoscaling): Autoscaling is automatically adding or removing compute resources, such as GPU instances, based on demand, so a system handles traffic spikes without paying for idle capacity. - [BabyAGI](https://agentik-os.com/glossary/babyagi): BabyAGI is a small open-source agent script that repeatedly creates, prioritizes and executes tasks toward an objective using a language model, and it was an early demonstration of task-driven autonomous agents. - [Background agent](https://agentik-os.com/glossary/background-agent): A background agent is an agent that runs asynchronously without a person watching each step, often triggered by events or schedules, and reports results or asks for input only when needed. - [Backpressure](https://agentik-os.com/glossary/backpressure): Backpressure is a mechanism by which a slower downstream component signals upstream components to slow down or pause, preventing queues from growing without limit when work arrives faster than it can be processed. - [Backpropagation](https://agentik-os.com/glossary/backpropagation): Backpropagation is the algorithm that computes how much each weight in a neural network contributed to the error, by applying the chain rule backward from the output layer to the input layer. - [Base model](https://agentik-os.com/glossary/base-model): A base model is a language model after pretraining but before instruction tuning or alignment. It continues text well but does not reliably follow instructions or hold a conversation. - [Batch inference](https://agentik-os.com/glossary/batch-inference): Batch inference is running a model on a large set of inputs as a background job rather than in real time, typically at lower cost, used when results are not needed immediately. - [Batch size](https://agentik-os.com/glossary/batch-size): Batch size is the number of training examples processed together before the model's parameters are updated. It affects training speed, memory use, and the stability of learning. - [Batching](https://agentik-os.com/glossary/batching): Batching is the technique of grouping multiple inputs or requests and processing them together on hardware such as a GPU, improving throughput and cost efficiency at the price of some added latency. - [BDI architecture](https://agentik-os.com/glossary/bdi-architecture): BDI architecture is a classic agent design that models an agent through its beliefs about the world, its desires or goals, and its intentions, the plans it has committed to carrying out. - [Beam search](https://agentik-os.com/glossary/beam-search): Beam search is a decoding strategy that keeps several of the most promising partial sequences at each step and extends them in parallel, choosing the highest-scoring complete sequence at the end. - [Benchmark](https://agentik-os.com/glossary/benchmark): A benchmark is a standardized dataset and scoring method used to compare AI models on the same task, such as reasoning, coding or knowledge questions, so results can be reported consistently across models and versions. - [BERT](https://agentik-os.com/glossary/bert): BERT is an encoder-only transformer language model introduced by Google that reads text in both directions at once. It is widely used for classification, search, and other language understanding tasks. - [Bi-encoder](https://agentik-os.com/glossary/bi-encoder): A bi-encoder is a retrieval model that encodes queries and documents separately into embeddings, so document vectors can be precomputed and compared quickly with any query at search time. - [Bias](https://agentik-os.com/glossary/bias): Bias in AI is a systematic skew in a model's outputs that unfairly favors or disadvantages certain groups or viewpoints, often inherited from unrepresentative training data or flawed design choices. - [Bias-variance tradeoff](https://agentik-os.com/glossary/bias-variance-tradeoff): The bias-variance tradeoff describes the tension between a model that is too simple and makes systematic errors, and one that is too sensitive to its training data and fails to generalize. - [Blackboard architecture](https://agentik-os.com/glossary/blackboard-architecture): Blackboard architecture is a design in which multiple specialized agents collaborate by reading from and writing to a shared workspace, the blackboard, each contributing when it can advance the solution. - [BLEU](https://agentik-os.com/glossary/bleu): BLEU is an automatic metric that scores machine-generated text, originally translations, by measuring how many word sequences it shares with one or more human reference texts. - [Blue-green deployment](https://agentik-os.com/glossary/blue-green-deployment): A blue-green deployment is a release strategy that runs two identical production environments and switches traffic from the current one to the new one at once, so rollback is a quick switch back. - [BM25](https://agentik-os.com/glossary/bm25): BM25 is a widely used ranking function for keyword search that scores documents by query term frequency and rarity, while adjusting for document length and limiting the effect of repeated terms. - [Brand voice](https://agentik-os.com/glossary/brand-voice): Brand voice is the constraint on what a company sounds like and what it must not claim. In Content OS it lives in the brief, not in the last chat message. A person still approves before a piece leaves. The agent does not get to invent a metric or a promise. - [Browser agent](https://agentik-os.com/glossary/browser-agent): A browser agent is an AI agent that completes tasks on websites by navigating pages, reading content, filling in forms and clicking elements inside a web browser on a user's behalf. - [Browser automation](https://agentik-os.com/glossary/browser-automation): Browser automation is the programmatic control of a web browser to load pages, interact with elements and extract data, often through a headless browser, and it is a common tool layer beneath browser agents. - [Byte pair encoding](https://agentik-os.com/glossary/byte-pair-encoding): Byte pair encoding is a tokenization method that starts from individual characters or bytes and repeatedly merges the most frequent adjacent pairs into new tokens, building a vocabulary of common subwords. - [Calibration](https://agentik-os.com/glossary/calibration): Calibration is how closely a model's stated confidence matches its actual accuracy, so a well-calibrated model that reports 80 percent confidence on a set of answers is right about 80 percent of the time. - [Canary deployment](https://agentik-os.com/glossary/canary-deployment): A canary deployment is a release strategy that sends a small share of traffic to a new version first, monitoring its behavior before gradually rolling it out to everyone. - [Cancellation](https://agentik-os.com/glossary/cancellation): Cancellation is the controlled stopping of a running task or workflow at a person's or system's request, ideally releasing resources and leaving partial work in a consistent state. - [Catastrophic forgetting](https://agentik-os.com/glossary/catastrophic-forgetting): Catastrophic forgetting is the tendency of a neural network to lose previously learned knowledge or skills when it is trained on new data or a new task. - [Chain-of-thought prompting](https://agentik-os.com/glossary/chain-of-thought-prompting): Chain-of-thought prompting is a technique that asks a language model to write out intermediate reasoning steps before its final answer, which often improves accuracy on math, logic and multi-step problems. - [Chain-of-verification](https://agentik-os.com/glossary/chain-of-verification): Chain-of-verification is a prompting method in which a model drafts an answer, generates questions to check its own claims, answers them independently and then revises the draft to reduce factual errors. - [Chat template](https://agentik-os.com/glossary/chat-template): A chat template is the formatting scheme that converts a list of role-tagged messages into the exact token sequence a chat model was trained on, using special markers to separate system, user and assistant turns. - [Checkpointing](https://agentik-os.com/glossary/checkpointing): Checkpointing is the practice of saving a workflow's or agent's state at intervals so that, after a crash, pause or human review, execution can resume from the last saved point instead of starting over. - [Choreography](https://agentik-os.com/glossary/choreography): Choreography is a coordination style in which each service or agent reacts to events and knows its own part of a process, so the overall workflow emerges without a central orchestrator directing it. - [Chunk overlap](https://agentik-os.com/glossary/chunk-overlap): Chunk overlap is the amount of text repeated at the boundary between consecutive chunks, used so that sentences or ideas cut by a split still appear intact in at least one chunk. - [Chunking](https://agentik-os.com/glossary/chunking): Chunking is splitting documents into smaller pieces, or chunks, before embedding and indexing them, so retrieval can return focused passages that fit within a model's context window. - [CI/CD](https://agentik-os.com/glossary/ci-cd): CI/CD is the practice of automatically building, testing and releasing software every time changes are made, and in AI projects it often includes running evaluations before deployment. - [Circuit breaker](https://agentik-os.com/glossary/circuit-breaker): A circuit breaker is a resilience pattern that stops sending requests to a failing service for a period after repeated errors, preventing cascading failures and giving the service time to recover. - [Citation](https://agentik-os.com/glossary/citation): A citation, in AI systems, is a reference that links a statement in a model's answer to the specific source document or passage that supports it, letting readers verify the claim. - [Classification](https://agentik-os.com/glossary/classification): Classification is a machine learning task in which a model assigns inputs to one of a set of categories, such as marking an email as spam or not spam. - [Claude](https://agentik-os.com/glossary/claude): Claude is a family of large language models and an AI assistant developed by Anthropic, used for tasks such as writing, analysis, coding, and conversation. - [Clustering](https://agentik-os.com/glossary/clustering): Clustering is an unsupervised learning task that groups data points so that items in the same group are more similar to each other than to items in other groups. - [Code interpreter](https://agentik-os.com/glossary/code-interpreter): A code interpreter is a tool that lets a language model write and run code, usually Python, in a sandbox and read the output, which it can use for calculations, data analysis, file conversion and charts. - [Code model](https://agentik-os.com/glossary/code-model): A code model is a language model trained or fine-tuned heavily on source code, specialized for tasks such as writing, completing, explaining, and fixing software. - [CodeAct](https://agentik-os.com/glossary/codeact): CodeAct is an agent approach in which the model expresses its actions as executable code, typically Python, rather than as individual JSON tool calls, letting it combine several operations with loops and variables in one step. - [Coding agent](https://agentik-os.com/glossary/coding-agent): A coding agent is an AI agent that works on software by reading a codebase, editing files, running commands and tests, and iterating on the results to implement features or fix bugs with limited human guidance. - [Cognitive architecture](https://agentik-os.com/glossary/cognitive-architecture): A cognitive architecture is the overall design of an intelligent agent, specifying how components such as memory, reasoning, planning, perception and action are organized and interact. - [Cold start](https://agentik-os.com/glossary/cold-start): A cold start is the extra delay when a service must start a new instance or load a model into memory before handling a request, common in serverless and scale-to-zero deployments. - [Compensating action](https://agentik-os.com/glossary/compensating-action): A compensating action is an operation that reverses the effects of a previously completed step, such as issuing a refund for a charge, used when a later step in a process fails. - [Completion](https://agentik-os.com/glossary/completion): A completion is the text a language model generates in response to a prompt. The term comes from early models that continued, or completed, whatever text they were given. - [Computer use](https://agentik-os.com/glossary/computer-use): Computer use is the capability of an AI agent to operate a graphical computer interface like a person does, reading screenshots and issuing mouse movements, clicks and keystrokes to complete tasks in ordinary applications. - [Computer vision](https://agentik-os.com/glossary/computer-vision): Computer vision is the field of AI that enables computers to interpret and analyze visual information from images and video, such as recognizing objects, faces, or text. - [Concept drift](https://agentik-os.com/glossary/concept-drift): Concept drift is a change over time in the relationship between inputs and the correct outputs, so a model's learned patterns become outdated and its accuracy declines even if inputs look similar. - [Concurrency limit](https://agentik-os.com/glossary/concurrency-limit): A concurrency limit is a cap on how many tasks, agent runs or requests may execute at the same time, used to protect downstream services, control cost and keep resource use predictable. - [Conditional branching](https://agentik-os.com/glossary/conditional-branching): Conditional branching is a workflow feature that sends execution down different paths depending on a condition, such as the output of a previous step, a classification result or a data value. - [Confidence score](https://agentik-os.com/glossary/confidence-score): A confidence score is a numerical value that a model or system attaches to an output to indicate how likely it is to be correct, often used to route uncertain cases to human review. - [Connector](https://agentik-os.com/glossary/connector): A connector is an integration that gives an AI assistant or agent authenticated access to an external service, such as email, a calendar or a database, so it can read data and take actions there. - [Consensus](https://agentik-os.com/glossary/consensus): Consensus is the process by which multiple agents or nodes agree on a single decision or value, for example through voting or a formal protocol, even when some participants disagree or fail. - [Constitutional AI](https://agentik-os.com/glossary/constitutional-ai): Constitutional AI is a training method developed by Anthropic in which a model is guided by a written set of principles, using AI-generated feedback based on those principles to become more helpful and harmless. - [Constrained decoding](https://agentik-os.com/glossary/constrained-decoding): Constrained decoding is a generation method that restricts which tokens a model may choose at each step so the output is guaranteed to follow a grammar, schema or regular expression. - [Container](https://agentik-os.com/glossary/container): A container is a lightweight, isolated package holding an application and everything it needs to run, such as libraries and settings, so it behaves the same on any machine, with Docker the best-known tool. - [Content moderation](https://agentik-os.com/glossary/content-moderation): Content moderation is the process of detecting and handling harmful, illegal or policy-violating content in user inputs or AI outputs, using automated classifiers, rules, human reviewers or a combination of these. - [Content provenance](https://agentik-os.com/glossary/content-provenance): Content provenance is verifiable information attached to digital media that records its origin and edit history, such as whether AI was used, with C2PA being the leading open technical standard for it. - [Context](https://agentik-os.com/glossary/context): Context is all the information a language model can see when producing a response, including the system prompt, conversation history, retrieved documents, tool results and the current request. - [Context compression](https://agentik-os.com/glossary/context-compression): Context compression is reducing the amount of text in a model's context, for example by summarizing old conversation turns or removing redundant content, so key information fits within the context window. - [Context engineering](https://agentik-os.com/glossary/context-engineering): Context engineering is the practice of deciding what information goes into a model's context at each step, including instructions, history, retrieved data and tool results, so it has what it needs without noise. - [Context poisoning](https://agentik-os.com/glossary/context-poisoning): Context poisoning is when incorrect, hallucinated or malicious information enters a model's context and is then repeatedly relied on in later steps, compounding errors over a long session. - [Context rot](https://agentik-os.com/glossary/context-rot): Context rot is the gradual decline in a language model's accuracy and instruction following as its context grows longer, even when the context remains within the model's maximum window. - [Context stuffing](https://agentik-os.com/glossary/context-stuffing): Context stuffing is the practice of placing large amounts of material, such as whole documents, directly into a prompt instead of retrieving only the relevant parts, which can raise cost and dilute attention. - [Context truncation](https://agentik-os.com/glossary/context-truncation): Context truncation is cutting text from a model's input, usually the oldest messages or the end of a document, when it would otherwise exceed the context window, which can silently drop needed information. - [Context window](https://agentik-os.com/glossary/context-window): The context window is the maximum amount of text, measured in tokens, that a language model can consider at once, including both the input it receives and the output it generates. - [Contextual retrieval](https://agentik-os.com/glossary/contextual-retrieval): Contextual retrieval is a retrieval-augmented generation technique that prepends a short, model-written summary of the surrounding document to each chunk before embedding and keyword indexing, so isolated chunks keep enough context to be found. - [Continued pretraining](https://agentik-os.com/glossary/continued-pretraining): Continued pretraining is the practice of extending a pretrained model's training on additional large unlabeled data, often from a specific domain or language, before any task-specific fine-tuning. - [Continuous batching](https://agentik-os.com/glossary/continuous-batching): Continuous batching is a serving technique that adds new requests to a running batch as soon as others finish, instead of waiting for the whole batch to complete, improving GPU utilization for language models. - [Contract net protocol](https://agentik-os.com/glossary/contract-net-protocol): The contract net protocol is a classic multi-agent coordination method in which a manager announces a task, agents submit bids describing how they would do it, and the manager awards the task to the best bidder. - [Conversation history](https://agentik-os.com/glossary/conversation-history): Conversation history is the record of previous messages in a chat that is sent back to a language model with each new turn, since the model itself keeps no memory between requests. - [Conversation memory](https://agentik-os.com/glossary/conversation-memory): Conversation memory is the mechanism that keeps earlier messages of a dialogue available to a language model on later turns, either by resending recent messages or storing and retrieving them. - [Conversational agent](https://agentik-os.com/glossary/conversational-agent): A conversational agent is a software system that interacts with people through natural language dialogue, in text or speech, to answer questions, complete requests or hold a conversation. - [Convolutional neural network](https://agentik-os.com/glossary/convolutional-neural-network): A convolutional neural network is a neural network that scans small learned filters across its input to detect local patterns such as edges and shapes. It is widely used for images. - [Corrective RAG](https://agentik-os.com/glossary/corrective-rag): Corrective RAG is a retrieval-augmented generation approach that evaluates the quality of retrieved documents and, when they seem irrelevant or insufficient, takes corrective steps such as refining the query or searching elsewhere. - [Cosine similarity](https://agentik-os.com/glossary/cosine-similarity): Cosine similarity is a measure of how similar two vectors are based on the angle between them, ranging from minus one to one, and is the most common way to compare embeddings. - [CrewAI](https://agentik-os.com/glossary/crewai): CrewAI is an open-source Python framework for building teams of role-based AI agents, called crews, that are given goals and tasks and collaborate to complete them. - [Critic agent](https://agentik-os.com/glossary/critic-agent): A critic agent is an agent whose job is to review the output of another agent, identify errors, gaps or rule violations, and return feedback that the producing agent uses to improve its work. - [Cross-encoder](https://agentik-os.com/glossary/cross-encoder): A cross-encoder is a model that reads a query and a document together and outputs a relevance score. It is more accurate than comparing separate embeddings but too slow for large collections, so it is used for reranking. - [Cross-entropy loss](https://agentik-os.com/glossary/cross-entropy-loss): Cross-entropy loss is a loss function that measures the gap between predicted probabilities and the true labels. It is the standard training objective for classification and for next-token prediction in language models. - [CUDA](https://agentik-os.com/glossary/cuda): CUDA is NVIDIA's parallel computing platform and programming model that lets software run general-purpose computations on NVIDIA GPUs, and it underpins most AI training and inference frameworks. - [Custom instructions](https://agentik-os.com/glossary/custom-instructions): Custom instructions are persistent preferences or rules a user sets once in an AI assistant, such as tone or background details, which are automatically added to every conversation. - [Customer service agent](https://agentik-os.com/glossary/customer-service-agent): A customer service agent, in AI, is an agent that answers customer questions and resolves requests such as order changes or refunds by using company knowledge and business systems, escalating to staff when needed. - [Data augmentation](https://agentik-os.com/glossary/data-augmentation): Data augmentation is a technique that expands a training dataset by creating modified copies of existing examples, such as rotated images or paraphrased sentences, to improve robustness and reduce overfitting. - [Data contamination](https://agentik-os.com/glossary/data-contamination): Data contamination is when examples from an evaluation benchmark appear in a model's training data, inflating its scores because the model may have memorized answers rather than learned the skill. - [Data drift](https://agentik-os.com/glossary/data-drift): Data drift is a change over time in the statistical properties of the inputs a model receives in production compared with its training data, which can quietly degrade its performance. - [Data lineage](https://agentik-os.com/glossary/data-lineage): Data lineage is a map of how data flows through systems, showing where it originated, which transformations were applied and where it is used, supporting debugging, impact analysis and compliance. - [Data minimization](https://agentik-os.com/glossary/data-minimization): Data minimization is the principle of collecting, processing and retaining only the personal data strictly necessary for a specific purpose, reducing privacy risk and exposure if a system is breached. - [Data poisoning](https://agentik-os.com/glossary/data-poisoning): Data poisoning is an attack in which an adversary inserts manipulated or malicious examples into a model's training or retrieval data to degrade its performance or plant hidden behaviors. - [Data provenance](https://agentik-os.com/glossary/data-provenance): Data provenance is the documented record of where data came from and how it was collected, transformed and used, allowing teams to verify its origin, usage rights and quality. - [Data residency](https://agentik-os.com/glossary/data-residency): Data residency is the requirement or guarantee that data is stored and processed within a specific country or region, often to satisfy laws, contracts or customer policies. - [Data warehouse](https://agentik-os.com/glossary/data-warehouse): A data warehouse is a central database optimized for analyzing large volumes of structured data gathered from many sources, used for reporting, business intelligence and increasingly AI applications. - [Dead-letter queue](https://agentik-os.com/glossary/dead-letter-queue): A dead-letter queue is a separate queue where messages or tasks are moved after they repeatedly fail or cannot be delivered, so they can be inspected and handled without blocking normal processing. - [Decentralized coordination](https://agentik-os.com/glossary/decentralized-coordination): Decentralized coordination is a way of organizing multiple agents in which they coordinate directly with each other as peers, without a single central controller making all decisions. - [Decision tree](https://agentik-os.com/glossary/decision-tree): A decision tree is a model that makes predictions by following a sequence of yes or no questions about input features, forming a branching structure that ends in a prediction. - [Decoder](https://agentik-os.com/glossary/decoder): A decoder is the part of a neural network that turns an internal representation into output, such as generating text one token at a time. Many large language models are decoder-only transformers. - [Decoder-only transformer](https://agentik-os.com/glossary/decoder-only-transformer): A decoder-only transformer is a transformer that uses only the decoder stack with causal attention, generating text left to right. Most large language models use this design. - [Deduplication](https://agentik-os.com/glossary/deduplication): Deduplication is the detection and removal of repeated messages, tasks or events, often by tracking unique identifiers, so that retries or duplicate deliveries do not cause the same work to run twice. - [Deep learning](https://agentik-os.com/glossary/deep-learning): Deep learning is a type of machine learning that uses neural networks with many stacked layers to learn complex patterns directly from raw data such as text, images, and audio. - [Deep research agent](https://agentik-os.com/glossary/deep-research-agent): A deep research agent is an agent that answers complex questions by running many searches, reading and comparing sources over an extended session, and writing a report with citations to what it found. - [Deepfake](https://agentik-os.com/glossary/deepfake): A deepfake is synthetic audio, image or video created with AI to realistically depict a person saying or doing something they never did, raising risks of fraud, disinformation and harassment. - [DeepSeek](https://agentik-os.com/glossary/deepseek): DeepSeek is a Chinese AI company and the name of its family of large language models, several of which are released with open weights, including reasoning models. - [Delegation](https://agentik-os.com/glossary/delegation): Delegation is the act of an agent assigning a task or subtask to another agent, tool or person, together with the instructions and context needed to complete it, and later receiving the result. - [Deliberative agent](https://agentik-os.com/glossary/deliberative-agent): A deliberative agent is an agent that keeps an internal model of its world and reasons about possible actions and their consequences, planning ahead before choosing what to do. - [Delimiters](https://agentik-os.com/glossary/delimiters): Delimiters are markers such as quotes, triple backticks or XML-style tags used in a prompt to clearly separate instructions from data, examples or documents so the model can tell them apart. - [Dense model](https://agentik-os.com/glossary/dense-model): A dense model is a neural network in which all parameters are used to process every input, in contrast to sparse architectures such as mixture of experts that activate only part of the network. - [Dense retrieval](https://agentik-os.com/glossary/dense-retrieval): Dense retrieval is finding relevant passages by comparing dense embedding vectors of the query and documents, which captures meaning and paraphrase better than exact keyword matching. - [Deployment](https://agentik-os.com/glossary/deployment): Deployment is the process of releasing a model or application into an environment where it serves real users, including packaging, configuration, infrastructure provisioning and verifying that it works. - [Deterministic replay](https://agentik-os.com/glossary/deterministic-replay): Deterministic replay is a technique that rebuilds a workflow's state by re-running its code against a recorded history of events and results, so it reaches the same point without repeating side effects. - [Differential privacy](https://agentik-os.com/glossary/differential-privacy): Differential privacy is a mathematical technique that adds carefully calibrated noise to data or computations so results reveal useful patterns while making it very hard to learn anything about any single individual. - [Diffusion model](https://agentik-os.com/glossary/diffusion-model): A diffusion model is a generative model that learns to create data by starting from random noise and removing it step by step. It is the dominant approach for image and video generation. - [Dimensionality reduction](https://agentik-os.com/glossary/dimensionality-reduction): Dimensionality reduction is a set of techniques that compress data with many features into fewer features while preserving its important structure, making it easier to visualize, store, or model. - [Directed acyclic graph](https://agentik-os.com/glossary/directed-acyclic-graph): A directed acyclic graph is a set of nodes connected by one-way edges with no cycles, commonly used to represent workflows where each step runs only after the steps it depends on have finished. - [Discriminative model](https://agentik-os.com/glossary/discriminative-model): A discriminative model learns to distinguish between categories by modeling the boundary between them, predicting labels from inputs rather than learning how the data itself is generated. - [Distributed lock](https://agentik-os.com/glossary/distributed-lock): A distributed lock is a mechanism that ensures only one process or agent across multiple machines can access a shared resource or perform an operation at a time. - [Distributed training](https://agentik-os.com/glossary/distributed-training): Distributed training is training a machine learning model across many GPUs or machines at once, splitting the data, the model or both, to handle larger models and finish training faster. - [Document parsing](https://agentik-os.com/glossary/document-parsing): Document parsing is extracting text, tables, headings and layout from files such as PDFs, slides or web pages into clean, structured content that can be chunked and indexed for retrieval. - [Document store](https://agentik-os.com/glossary/document-store): A document store is a database or storage layer that holds source documents and their metadata so they can be indexed, retrieved and returned alongside search results. - [Domain-specific model](https://agentik-os.com/glossary/domain-specific-model): A domain-specific model is an AI model trained or fine-tuned for a particular field, such as medicine, law, or finance, to perform better on its terminology and tasks than a general model. - [Dot product similarity](https://agentik-os.com/glossary/dot-product-similarity): Dot product similarity is a measure that multiplies two vectors element by element and sums the results. For normalized vectors it gives the same ranking as cosine similarity. - [DPO](https://agentik-os.com/glossary/dpo): DPO, or direct preference optimization, is a method for aligning a language model with preference data by training directly on pairs of preferred and rejected responses, without a separate reward model. - [Dropout](https://agentik-os.com/glossary/dropout): Dropout is a regularization technique that randomly switches off a fraction of neurons during each training step, forcing the network to learn redundant, more robust features and reducing overfitting. - [Durable execution](https://agentik-os.com/glossary/durable-execution): Durable execution is an approach in which a platform records each step of a running workflow so that it can survive crashes, restarts and long waits and continue exactly where it left off. - [Edge AI](https://agentik-os.com/glossary/edge-ai): Edge AI is running AI models directly on local devices, such as phones, cameras, vehicles or industrial equipment, instead of in a remote cloud, reducing latency and keeping data local. - [Embedding](https://agentik-os.com/glossary/embedding): An embedding is a list of numbers, or vector, that represents the meaning of a piece of content such as a word, sentence, image or document, so that similar content ends up with similar vectors. - [Embedding dimension](https://agentik-os.com/glossary/embedding-dimension): Embedding dimension is the number of values in each embedding vector. Higher dimensions can capture more nuance but require more storage and computation for search. - [Embedding model](https://agentik-os.com/glossary/embedding-model): An embedding model is a neural network that converts text, images or other content into embedding vectors, used for semantic search, clustering, recommendation and retrieval-augmented generation. - [Embedding quantization](https://agentik-os.com/glossary/embedding-quantization): Embedding quantization is storing embedding values at lower numeric precision, such as 8-bit integers or single bits, to reduce memory use and speed up search at some cost to accuracy. - [Embodied agent](https://agentik-os.com/glossary/embodied-agent): An embodied agent is an AI agent that perceives and acts through a physical or simulated body, such as a robot or a character in a 3D environment, rather than only through text or software tools. - [Emergent abilities](https://agentik-os.com/glossary/emergent-abilities): Emergent abilities are capabilities that appear in larger language models but are absent or weak in smaller ones. Researchers debate how much of this effect reflects how performance is measured. - [Encoder](https://agentik-os.com/glossary/encoder): An encoder is the part of a neural network that transforms input data into an internal representation capturing its meaning, which other components can then use for prediction or generation. - [Encoder-decoder architecture](https://agentik-os.com/glossary/encoder-decoder-architecture): An encoder-decoder architecture pairs an encoder that reads the input with a decoder that generates the output. It is commonly used for tasks such as translation and summarization. - [Encryption at rest](https://agentik-os.com/glossary/encryption-at-rest): Encryption at rest is the protection of stored data, such as databases, logs and model files, by encrypting it on disk so it cannot be read if the storage is accessed without authorization. - [Encryption in transit](https://agentik-os.com/glossary/encryption-in-transit): Encryption in transit is the protection of data while it moves between systems, such as between an application and an AI API, typically using TLS so it cannot be read or altered along the way. - [End-of-sequence token](https://agentik-os.com/glossary/end-of-sequence-token): An end-of-sequence token is a special token a language model generates to signal that its output is complete, which tells the system to stop generating further text. - [Ensemble learning](https://agentik-os.com/glossary/ensemble-learning): Ensemble learning is an approach that combines the predictions of several models to achieve better accuracy or robustness than any single model alone. - [Episodic memory](https://agentik-os.com/glossary/episodic-memory): Episodic memory in AI agents is a record of specific past events and interactions, such as previous conversations or task attempts, that the agent can recall to inform similar future situations. - [Epoch](https://agentik-os.com/glossary/epoch): An epoch is one complete pass of a learning algorithm through the entire training dataset. Models are often trained for several epochs, though large language models may see most data only once. - [Escalation](https://agentik-os.com/glossary/escalation): Escalation is the handover of a task from an agent to a person or a more capable agent when it meets a situation it cannot or should not handle, such as low confidence, policy limits or repeated failure. - [ETL](https://agentik-os.com/glossary/etl): ETL is a data integration process that extracts data from source systems, transforms it into a consistent format and loads it into a target system such as a data warehouse. - [EU AI Act](https://agentik-os.com/glossary/eu-ai-act): The EU AI Act is the European Union's regulation governing artificial intelligence, which classifies AI systems by risk level and sets obligations such as transparency, documentation and human oversight for providers and deployers. - [Euclidean distance](https://agentik-os.com/glossary/euclidean-distance): Euclidean distance is the straight-line distance between two vectors in space, used in vector search where smaller distances indicate more similar items. - [Eval harness](https://agentik-os.com/glossary/eval-harness): An eval harness is software that runs a set of evaluation cases against a model or AI system, collects the outputs, applies scoring and reports results so tests can be repeated automatically. - [Evaluation](https://agentik-os.com/glossary/evaluation): An evaluation is a structured test that measures how well an AI model or system performs on a defined task, using prepared inputs, expected outputs or scoring rules, and metrics that can be tracked over time. - [Evaluation rubric](https://agentik-os.com/glossary/evaluation-rubric): An evaluation rubric is a written set of criteria and scoring levels that describes what good and bad outputs look like, used by human graders or LLM judges to score AI responses consistently. - [Evaluator-optimizer](https://agentik-os.com/glossary/evaluator-optimizer): Evaluator-optimizer is a workflow pattern in which one model call produces a result and another evaluates it and gives feedback, repeating in a loop until the result meets the defined criteria. - [Event bus](https://agentik-os.com/glossary/event-bus): An event bus is a shared channel that carries events between components of a system, letting any component publish events and others listen for the ones they care about. - [Event sourcing](https://agentik-os.com/glossary/event-sourcing): Event sourcing is a design pattern that stores every change to a system's state as an ordered log of events, so the current state can be rebuilt, audited or replayed from that history. - [Event-driven architecture](https://agentik-os.com/glossary/event-driven-architecture): Event-driven architecture is a software design in which components communicate by producing and reacting to events, such as a new message or a completed task, instead of calling each other directly. - [Exactly-once processing](https://agentik-os.com/glossary/exactly-once-processing): Exactly-once processing is a guarantee that each message or task affects the system's result one time only, usually achieved by combining retries with deduplication or idempotent operations. - [Excessive agency](https://agentik-os.com/glossary/excessive-agency): Excessive agency is a security risk in which an AI agent has more permissions, tools or autonomy than its task requires, allowing a manipulated or mistaken agent to take damaging actions. - [Explainability](https://agentik-os.com/glossary/explainability): Explainability is the ability to describe, in terms people can understand, why an AI system produced a particular output or decision, supporting trust, debugging and regulatory accountability. - [F1 score](https://agentik-os.com/glossary/f1-score): The F1 score is an evaluation metric that combines precision and recall into a single number using their harmonic mean, useful when both false positives and false negatives matter. - [Factuality](https://agentik-os.com/glossary/factuality): Factuality is the degree to which an AI model's statements are true according to reliable real-world knowledge, evaluated by checking its claims against trusted reference sources. - [Failover](https://agentik-os.com/glossary/failover): Failover is the automatic switch from a failed component, such as a server, service or model provider, to a standby replacement so that work can continue with minimal interruption. - [Fairness](https://agentik-os.com/glossary/fairness): Fairness in AI is the goal of ensuring a system's decisions and outputs do not produce unjustified differences in treatment or outcomes across groups, measured using defined fairness metrics and audits. - [FAISS](https://agentik-os.com/glossary/faiss): FAISS is an open-source library from Meta for efficient similarity search and clustering of dense vectors, offering exact and approximate nearest neighbor indexes that can run on CPUs or GPUs. - [Fallback](https://agentik-os.com/glossary/fallback): A fallback is an alternative path used when the primary one fails, such as switching to a different model, tool or cached answer, so a workflow can still produce a usable result. - [Fallback model](https://agentik-os.com/glossary/fallback-model): A fallback model is an alternative model that an application switches to automatically when the primary model fails, times out or hits a rate limit, keeping the service available. - [Fan-in](https://agentik-os.com/glossary/fan-in): Fan-in is an orchestration step in which the results of many parallel subtasks are collected and combined into a single output once they finish, often after waiting for all of them. - [Fan-out](https://agentik-os.com/glossary/fan-out): Fan-out is an orchestration step in which one task is split into many parallel subtasks, sent to multiple agents, workers or model calls at the same time. - [Feature](https://agentik-os.com/glossary/feature): A feature is an individual measurable property of the data used as input to a model, such as a word count, a pixel value, or a customer's age. - [Feature engineering](https://agentik-os.com/glossary/feature-engineering): Feature engineering is the practice of selecting, transforming, or creating input variables from raw data to help a machine learning model learn more effectively. - [Feature store](https://agentik-os.com/glossary/feature-store): A feature store is a centralized system for defining, storing and serving the input features used by machine learning models, ensuring the same values are used in training and in production. - [Few-shot prompting](https://agentik-os.com/glossary/few-shot-prompting): Few-shot prompting is including a small number of worked examples of inputs and desired outputs in a prompt so the model can infer the pattern, format or style to follow for a new input. - [Fine-tuning](https://agentik-os.com/glossary/fine-tuning): Fine-tuning is the process of further training a pretrained model on a smaller, task-specific or domain-specific dataset so it performs better on that task or adopts a particular behavior. - [FinOps](https://agentik-os.com/glossary/finops): FinOps is the practice of managing and optimizing cloud and AI spending through shared visibility, accountability and continuous cost tracking across engineering, finance and business teams. - [FLOPS](https://agentik-os.com/glossary/flops): FLOPS, short for floating point operations per second, is a measure of computing speed used to describe AI hardware performance, while the related term FLOPs counts the total operations a computation requires. - [Forward pass](https://agentik-os.com/glossary/forward-pass): A forward pass is the process of feeding input data through a neural network layer by layer to produce an output. During training it is followed by a backward pass that computes gradients. - [Foundation model](https://agentik-os.com/glossary/foundation-model): A foundation model is a large model trained on broad data that can be adapted to many downstream tasks through prompting or fine-tuning, rather than being built for one purpose. - [Fractional chief AI officer](https://agentik-os.com/glossary/fractional-chief-ai-officer): A fractional chief AI officer is a senior AI lead a company does not hire full time. Agentik on demand is narrower: we scope a gap the official OS do not cover, then install. There is no public retainer menu. Marketplace amounts are listed on Pricing, not on this term. - [Frontier model](https://agentik-os.com/glossary/frontier-model): A frontier model is one of the most capable AI models available at a given time, typically very large and trained with substantial compute, pushing the current limits of performance. - [Full-text search](https://agentik-os.com/glossary/full-text-search): Full-text search is searching the complete text of documents for query terms, usually with an inverted index and features such as stemming, phrase matching and relevance ranking. - [GDPR](https://agentik-os.com/glossary/gdpr): The GDPR is the European Union's data protection law, which governs how organizations collect, process and store personal data, including data used to train or operate AI systems, and grants individuals rights over their data. - [Gemini](https://agentik-os.com/glossary/gemini): Gemini is a family of multimodal large language models developed by Google DeepMind, able to process text, images, audio, and video. - [Generalization](https://agentik-os.com/glossary/generalization): Generalization is a model's ability to perform well on new data it did not see during training. It is the central goal of machine learning, as opposed to memorizing examples. - [Generated knowledge prompting](https://agentik-os.com/glossary/generated-knowledge-prompting): Generated knowledge prompting is a technique in which a language model first produces relevant facts or background knowledge about a question and then uses that generated knowledge as context to answer it. - [Generative adversarial network](https://agentik-os.com/glossary/generative-adversarial-network): A generative adversarial network trains two neural networks against each other: a generator that creates fake samples and a discriminator that tries to tell them apart from real data. - [Generative AI](https://agentik-os.com/glossary/generative-ai): Generative AI refers to artificial intelligence systems that create new content, such as text, images, code, audio, or video, based on patterns learned from large amounts of training data. - [Generative model](https://agentik-os.com/glossary/generative-model): A generative model learns the underlying distribution of its training data so it can produce new samples that resemble it, such as text, images, or audio. - [Go-to-market](https://agentik-os.com/glossary/go-to-market): Go-to-market, here, is the work Growth OS holds: audience, offer, and the next experiment. It sits next to Content OS on purpose. One writes. One looks for where the writing should go. Growth OS does not publish or spend for you. - [Goal decomposition](https://agentik-os.com/glossary/goal-decomposition): Goal decomposition is the process of breaking a broad objective into smaller, concrete subgoals or tasks that an agent or group of agents can complete one at a time and combine into a result. - [Goal-based agent](https://agentik-os.com/glossary/goal-based-agent): A goal-based agent is an agent that chooses actions by considering whether they bring it closer to an explicit goal, rather than reacting only to its current input. - [Golden dataset](https://agentik-os.com/glossary/golden-dataset): A golden dataset is a curated collection of inputs paired with verified correct or ideal outputs, used as a trusted reference to evaluate AI systems and detect quality changes between versions. - [GPT](https://agentik-os.com/glossary/gpt): GPT, short for generative pre-trained transformer, is a family of large language models developed by OpenAI. The term is also used loosely for any decoder-only transformer trained to generate text. - [GPU](https://agentik-os.com/glossary/gpu): A GPU is a processor with thousands of cores designed for parallel computation, originally built for graphics and now the main hardware used to train and run AI models. - [Graceful degradation](https://agentik-os.com/glossary/graceful-degradation): Graceful degradation is a design approach in which a system keeps providing reduced but useful service when some components fail, rather than failing completely. - [Gradient](https://agentik-os.com/glossary/gradient): A gradient is a vector of partial derivatives showing how a function's output changes as each input changes. In machine learning it indicates how to adjust each parameter to reduce the loss. - [Gradient descent](https://agentik-os.com/glossary/gradient-descent): Gradient descent is an optimization method that repeatedly adjusts a model's parameters in the direction that most reduces the loss, taking small steps guided by the gradient. - [Graph database](https://agentik-os.com/glossary/graph-database): A graph database is a database that stores data as nodes and edges with properties, optimized for queries that traverse relationships, and is commonly used to host knowledge graphs. - [Graph of thoughts](https://agentik-os.com/glossary/graph-of-thoughts): Graph of thoughts is a prompting framework that represents a model's intermediate reasoning steps as nodes in a graph, allowing ideas to be combined, refined and revisited instead of only branching like a tree. - [GraphRAG](https://agentik-os.com/glossary/graphrag): GraphRAG is a retrieval-augmented generation approach that builds a knowledge graph of entities and relationships from source documents and uses it to retrieve connected information and answer broad questions. - [Greedy decoding](https://agentik-os.com/glossary/greedy-decoding): Greedy decoding is a text generation strategy that always selects the single most probable next token. It is deterministic in principle but can produce repetitive or less natural text. - [Ground truth](https://agentik-os.com/glossary/ground-truth): Ground truth is the correct, verified answer or label for a data example, used as the reference against which a model's predictions are trained and evaluated. - [Groundedness](https://agentik-os.com/glossary/groundedness): Groundedness is the extent to which a model's answer is supported by the source material it was given, such as retrieved documents, rather than by unsupported claims or outside assumptions. - [Grounding](https://agentik-os.com/glossary/grounding): Grounding is tying a language model's output to verifiable sources, such as retrieved documents, databases or search results, so its claims are supported by evidence rather than only its training data. - [Grouped-query attention](https://agentik-os.com/glossary/grouped-query-attention): Grouped-query attention is a transformer attention variant in which several query heads share the same key and value heads, reducing memory use during inference with little loss in quality. - [GRPO](https://agentik-os.com/glossary/grpo): GRPO, or group relative policy optimization, is a reinforcement learning method that scores each response relative to a group of responses sampled for the same prompt, avoiding a separate value model. - [Guardrail](https://agentik-os.com/glossary/guardrail): A guardrail is a control placed around an AI model that checks, filters or constrains its inputs and outputs, for example blocking unsafe content, enforcing formats or preventing actions outside an allowed scope. - [Hallucination](https://agentik-os.com/glossary/hallucination): A hallucination is output from an AI model that sounds plausible but is false, unsupported, or invented, such as a fabricated fact, quotation, or citation. - [Hallucination rate](https://agentik-os.com/glossary/hallucination-rate): Hallucination rate is the proportion of a model's outputs that contain fabricated or unsupported claims, measured on a defined test set and used to compare models or track reliability over time. - [Handoff](https://agentik-os.com/glossary/handoff): A handoff is the transfer of an ongoing task or conversation from one agent to another, usually together with the relevant context, so the receiving agent can continue the work in its area of specialty. - [Heartbeat](https://agentik-os.com/glossary/heartbeat): A heartbeat is a periodic signal a running worker or agent sends to show it is still alive and making progress, so the orchestrator can detect stalled or crashed work and reassign it. - [Hidden layer](https://agentik-os.com/glossary/hidden-layer): A hidden layer is any layer in a neural network between the input and output layers. Hidden layers transform data into intermediate representations that capture increasingly abstract features. - [Hierarchical agents](https://agentik-os.com/glossary/hierarchical-agents): Hierarchical agents are a multi-agent structure arranged in levels, where higher-level agents set goals and delegate to lower-level agents, which may in turn manage their own subordinate agents. - [High-risk AI system](https://agentik-os.com/glossary/high-risk-ai-system): A high-risk AI system is a category defined by the EU AI Act for AI used in sensitive areas, such as employment, credit, education or critical infrastructure, which must meet strict requirements before and after deployment. - [HNSW](https://agentik-os.com/glossary/hnsw): HNSW is an approximate nearest neighbor algorithm that organizes vectors into layered proximity graphs, letting searches move quickly from coarse to fine layers toward the closest matches. - [Hook](https://agentik-os.com/glossary/hook): A hook is a user-defined command or function that an agent harness runs automatically at a specific point in the agent's lifecycle, for example before a tool call or after a response, to validate, block or log activity. - [Hugging Face Hub](https://agentik-os.com/glossary/hugging-face-hub): The Hugging Face Hub is an online platform hosting a large collection of open models, datasets and demo applications, where developers share, download and version machine learning assets. - [Human approval gate](https://agentik-os.com/glossary/human-approval-gate): A human approval gate is a checkpoint in an automated workflow where execution pauses until a person reviews and approves, edits or rejects a proposed action, typically used for sensitive or irreversible steps. - [Human evaluation](https://agentik-os.com/glossary/human-evaluation): Human evaluation is the assessment of AI outputs by people, who rate or compare responses on criteria such as accuracy, helpfulness and tone, often serving as the reference for automated metrics. - [Human in the loop](https://agentik-os.com/glossary/human-in-the-loop): Human in the loop means a named person still owns the send, the publish, and the write to a system of record. The agent may draft and propose. It does not get to decide that the draft already shipped. On Agentik that gate is a product rule, not a legal opinion. - [Human oversight](https://agentik-os.com/glossary/human-oversight): Human oversight is the set of measures that let people monitor, understand, intervene in and override an AI system's operation, and it is a legal requirement for high-risk systems under the EU AI Act. - [Human-on-the-loop](https://agentik-os.com/glossary/human-on-the-loop): Human-on-the-loop is an oversight model in which an automated system acts on its own while a person monitors its activity and can intervene or stop it, rather than approving each action in advance. - [HumanEval](https://agentik-os.com/glossary/humaneval): HumanEval is a code generation benchmark released by OpenAI consisting of programming problems with unit tests, where a model's generated functions are scored by whether they pass the tests. - [Hybrid search](https://agentik-os.com/glossary/hybrid-search): Hybrid search combines keyword search, such as BM25, with vector search and merges the results, so a system catches both exact term matches and semantically related content. - [HyDE](https://agentik-os.com/glossary/hyde): HyDE is a retrieval technique in which a language model first writes a hypothetical answer to the query, and the embedding of that answer is used to search for real documents similar to it. - [Hyperparameter](https://agentik-os.com/glossary/hyperparameter): A hyperparameter is a setting chosen before training rather than learned from data, such as the learning rate, batch size, or number of layers. Hyperparameters shape how a model learns. - [Idempotency](https://agentik-os.com/glossary/idempotency): Idempotency is the property of an operation that produces the same result whether it runs once or many times, which makes it safe to retry steps after failures without duplicating effects. - [In-context learning](https://agentik-os.com/glossary/in-context-learning): In-context learning is the ability of a language model to pick up a new task from instructions or examples placed in its prompt, without any change to its underlying weights. - [Indexing](https://agentik-os.com/glossary/indexing): Indexing is organizing content into a data structure, such as an inverted index or vector index, that allows fast lookup of matching items at query time instead of scanning everything. - [Indirect prompt injection](https://agentik-os.com/glossary/indirect-prompt-injection): Indirect prompt injection is a prompt injection hidden in content a model processes, such as a web page, email or document, rather than typed by the user, so the attack arrives through retrieved data. - [Inference](https://agentik-os.com/glossary/inference): Inference is the process of running a trained AI model on new input to produce an output, such as generating a text response, as opposed to training, which creates or updates the model. - [Inference endpoint](https://agentik-os.com/glossary/inference-endpoint): An inference endpoint is a network address, usually an HTTPS URL, where a deployed model accepts requests and returns predictions or generated outputs to calling applications. - [Inference server](https://agentik-os.com/glossary/inference-server): An inference server is software that loads AI models into memory and answers prediction or generation requests over a network, with features such as batching, multi-model hosting and metrics. - [Infrastructure as code](https://agentik-os.com/glossary/infrastructure-as-code): Infrastructure as code is managing servers, networks and cloud resources through version-controlled configuration files rather than manual setup, making environments reproducible and changes reviewable. - [Ingestion pipeline](https://agentik-os.com/glossary/ingestion-pipeline): An ingestion pipeline is the process that loads source content, cleans and parses it, splits it into chunks, generates embeddings and writes the results into an index for later retrieval. - [Input token](https://agentik-os.com/glossary/input-token): An input token is a token in the text sent to a language model, including instructions, history and documents. Many providers count and price input tokens separately from output tokens. - [Instruct model](https://agentik-os.com/glossary/instruct-model): An instruct model is a language model fine-tuned to follow user instructions and respond helpfully, as opposed to a base model that simply continues whatever text it is given. - [Instruction hierarchy](https://agentik-os.com/glossary/instruction-hierarchy): Instruction hierarchy is a principle for training and prompting models to give different priority to instructions by source, so system instructions outrank user messages, which outrank text found in tool results or documents. - [Instruction tuning](https://agentik-os.com/glossary/instruction-tuning): Instruction tuning is fine-tuning a language model on many examples of instructions paired with good responses, so it learns to follow natural language requests across a wide range of tasks. - [Inter-annotator agreement](https://agentik-os.com/glossary/inter-annotator-agreement): Inter-annotator agreement is a measure of how consistently different human reviewers label or rate the same items, used to check that evaluation guidelines are clear and that labels are reliable. - [Interpretability](https://agentik-os.com/glossary/interpretability): Interpretability is the degree to which humans can understand the internal workings of an AI model, such as which features or components drive its behavior, rather than only observing its inputs and outputs. - [Inverted index](https://agentik-os.com/glossary/inverted-index): An inverted index is a data structure that maps each word to the list of documents that contain it, allowing a search engine to find matching documents for a query very quickly. - [ISO/IEC 42001](https://agentik-os.com/glossary/iso-iec-42001): ISO/IEC 42001 is an international standard that specifies requirements for an AI management system, helping organizations establish policies, processes and controls for developing and using AI responsibly, with the option of certification. - [Iteration limit](https://agentik-os.com/glossary/iteration-limit): An iteration limit is a cap on the number of steps, tool calls or loop cycles an agent may perform on a task, used to prevent runaway loops and to bound cost and running time. - [IVF index](https://agentik-os.com/glossary/ivf-index): An IVF index is an approximate nearest neighbor index that clusters vectors into groups around centroids and, at query time, searches only the clusters closest to the query. - [Jailbreak](https://agentik-os.com/glossary/jailbreak): A jailbreak is a prompt or technique crafted to make an AI model bypass its safety rules or usage policies, causing it to produce content or take actions it was designed to refuse. - [JSON mode](https://agentik-os.com/glossary/json-mode): JSON mode is a model setting that constrains responses to be syntactically valid JSON, which helps applications parse output, though it does not by itself guarantee a particular schema. - [JSON Schema](https://agentik-os.com/glossary/json-schema): JSON Schema is a standard vocabulary for describing the structure of JSON data, and it is widely used to define the parameters of tools that language models can call and to validate their arguments. - [k-nearest neighbors](https://agentik-os.com/glossary/k-nearest-neighbors): k-nearest neighbors search is finding the k stored vectors closest to a query vector. Done exactly, it compares the query with every vector, which becomes slow for large collections. - [Keyword search](https://agentik-os.com/glossary/keyword-search): Keyword search is retrieval that matches the literal words in a query against words in documents, which is precise for names, codes and exact phrases but misses synonyms and paraphrases. - [Knowledge base](https://agentik-os.com/glossary/knowledge-base): A knowledge base is an organized collection of information, such as documents, articles or structured facts, that people or AI systems can search and draw on to answer questions. - [Knowledge cutoff](https://agentik-os.com/glossary/knowledge-cutoff): A knowledge cutoff is the date after which a model's training data ends. The model has no built-in knowledge of events after that point unless given it in the prompt or through tools. - [Knowledge distillation](https://agentik-os.com/glossary/knowledge-distillation): Knowledge distillation is a technique for training a smaller student model to imitate the outputs of a larger teacher model, producing a faster, cheaper model that retains much of the teacher's ability. - [Knowledge graph](https://agentik-os.com/glossary/knowledge-graph): A knowledge graph is a structured representation of information as entities, such as people, places or products, connected by labeled relationships, which supports precise lookups and reasoning over connections. - [Kubernetes](https://agentik-os.com/glossary/kubernetes): Kubernetes is an open-source system for deploying, scaling and managing containerized applications across clusters of machines, widely used to run model serving and other AI workloads. - [KV cache](https://agentik-os.com/glossary/kv-cache): A KV cache is memory that stores the attention keys and values computed for earlier tokens during generation, so a language model does not recompute them for each new token, speeding up inference. - [Label](https://agentik-os.com/glossary/label): A label is the known answer attached to a training example, such as the category of an image or the sentiment of a review. Supervised learning models learn to predict labels from inputs. - [LangChain](https://agentik-os.com/glossary/langchain): LangChain is an open-source framework for building applications with language models, providing components for prompts, model calls, tools, retrieval and agents that can be combined into larger systems. - [LangGraph](https://agentik-os.com/glossary/langgraph): LangGraph is an open-source library from the LangChain team for building stateful agent workflows as graphs of nodes and edges, supporting loops, persistence and pauses for human input. - [Language model](https://agentik-os.com/glossary/language-model): A language model is a system that assigns probabilities to sequences of words or tokens, allowing it to predict likely next text and, in modern forms, to generate fluent language. - [Large language model](https://agentik-os.com/glossary/large-language-model): A large language model is a neural network, usually a transformer, trained on vast amounts of text to predict the next token, which lets it generate, summarize, translate, and reason about language. - [Late interaction](https://agentik-os.com/glossary/late-interaction): Late interaction is a retrieval approach, popularized by ColBERT, that keeps one embedding per token for queries and documents and scores relevance by matching those token vectors at search time. - [Latency](https://agentik-os.com/glossary/latency): Latency is the time between sending a request to an AI system and receiving its response, a key measure of how responsive an application feels to its users. - [Latent space](https://agentik-os.com/glossary/latent-space): Latent space is the internal, compressed representation space a model learns, in which data points are arranged so that similar concepts are near each other. - [Layer normalization](https://agentik-os.com/glossary/layer-normalization): Layer normalization is a technique that rescales the values within each individual example across a layer's features. It is standard in transformer models because it does not depend on batch size. - [Leader election](https://agentik-os.com/glossary/leader-election): Leader election is a process by which a group of distributed nodes or agents chooses one member to act as coordinator, and chooses a new one automatically if the current leader fails. - [Leaderboard](https://agentik-os.com/glossary/leaderboard): A leaderboard is a public ranking of AI models based on their scores on one or more benchmarks or on human preference votes, used to compare models at a glance. - [Learning rate](https://agentik-os.com/glossary/learning-rate): The learning rate is a hyperparameter that sets how large each parameter update is during training. Too high a value can make training unstable, while too low a value makes it slow. - [Least privilege](https://agentik-os.com/glossary/least-privilege): Least privilege is the security principle of giving each user, service or AI agent only the minimum permissions needed to do its job, limiting the damage if it is misused or compromised. - [Least-to-most prompting](https://agentik-os.com/glossary/least-to-most-prompting): Least-to-most prompting is a technique that first asks a language model to break a hard problem into simpler subproblems, then solves them in order, feeding each answer into the next step. - [Llama](https://agentik-os.com/glossary/llama): Llama is a family of large language models released by Meta with openly downloadable weights, widely used as a base for research, fine-tuning, and self-hosted applications. - [llama.cpp](https://agentik-os.com/glossary/llama-cpp): llama.cpp is an open-source C and C++ project for running large language models efficiently on local hardware, including CPUs and consumer GPUs, and it introduced the widely used GGUF model file format. - [LLM-as-a-judge](https://agentik-os.com/glossary/llm-as-a-judge): LLM-as-a-judge is an evaluation method in which a language model scores or compares the outputs of another model against a rubric, offering scalable grading that should be checked against human judgments for reliability. - [LLMOps](https://agentik-os.com/glossary/llmops): LLMOps is the adaptation of MLOps to applications built on large language models, covering prompt and model versioning, evaluation, cost and latency monitoring, tracing and safe deployment. - [Load balancing](https://agentik-os.com/glossary/load-balancing): Load balancing is distributing incoming requests across multiple servers or model instances so no single one is overwhelmed, improving throughput, reliability and response times. - [Locality-sensitive hashing](https://agentik-os.com/glossary/locality-sensitive-hashing): Locality-sensitive hashing is a technique that hashes vectors so that similar items are likely to land in the same bucket, allowing fast approximate similarity search by comparing only items within matching buckets. - [Logits](https://agentik-os.com/glossary/logits): Logits are the raw, unnormalized scores a model outputs for each possible class or token before they are converted into probabilities, usually with a softmax function. - [Logprobs](https://agentik-os.com/glossary/logprobs): Logprobs are the log probabilities a language model assigns to generated tokens and alternative candidates. They are used to gauge model confidence, rank outputs, and analyze behavior. - [Long-horizon task](https://agentik-os.com/glossary/long-horizon-task): A long-horizon task is a task that requires an agent to plan and carry out many dependent steps over an extended period, where early mistakes can compound and keeping track of progress becomes difficult. - [Long-running task](https://agentik-os.com/glossary/long-running-task): A long-running task is a job that takes minutes, hours or longer to finish, requiring the system to track its progress, persist its state and report its result without holding an open request. - [Long-term memory](https://agentik-os.com/glossary/long-term-memory): Long-term memory in AI agents is information stored outside the model, in a database or files, that persists across sessions and can be retrieved later to inform new tasks or conversations. - [LoRA](https://agentik-os.com/glossary/lora): LoRA, or low-rank adaptation, is a parameter-efficient fine-tuning method that freezes a model's original weights and trains small low-rank matrices added to them, making customization far cheaper. - [Loss function](https://agentik-os.com/glossary/loss-function): A loss function is a formula that measures how far a model's predictions are from the correct answers. Training aims to minimize this value by adjusting the model's parameters. - [Lost in the middle](https://agentik-os.com/glossary/lost-in-the-middle): Lost in the middle is the observed tendency of language models to use information at the beginning and end of a long context more reliably than information placed in the middle. - [LSTM](https://agentik-os.com/glossary/lstm): LSTM, or long short-term memory, is a type of recurrent neural network that uses gates to control what information is kept or forgotten, helping it learn longer-range patterns in sequences. - [Machine learning](https://agentik-os.com/glossary/machine-learning): Machine learning is a branch of artificial intelligence in which systems learn patterns from data to make predictions or decisions, instead of following rules written explicitly by a programmer. - [Majority voting](https://agentik-os.com/glossary/majority-voting): Majority voting is a method of combining several independent answers, from different agents or repeated model runs, by selecting the answer that appears most often. - [Map-reduce](https://agentik-os.com/glossary/map-reduce): Map-reduce is a pattern in which the same operation is applied independently to many pieces of input, the map step, and the partial results are then merged into one answer, the reduce step. - [Masked language modeling](https://agentik-os.com/glossary/masked-language-modeling): Masked language modeling is a training objective in which some tokens in a sentence are hidden and the model learns to predict them from surrounding context. It is used to train models such as BERT. - [Matryoshka embeddings](https://agentik-os.com/glossary/matryoshka-embeddings): Matryoshka embeddings are embeddings trained so that their first dimensions carry the most information, allowing vectors to be truncated to shorter lengths to save storage and compute with limited loss in quality. - [Max tokens](https://agentik-os.com/glossary/max-tokens): Max tokens is a request parameter that caps how many tokens a language model may generate in a single response, after which output is cut off even if unfinished. - [Maximal marginal relevance](https://agentik-os.com/glossary/maximal-marginal-relevance): Maximal marginal relevance is a result selection method that balances relevance to the query against similarity to results already chosen, so the final set is both relevant and diverse. - [MCP server](https://agentik-os.com/glossary/mcp-server): An MCP server is a system a host can call through the Model Context Protocol. Agentik's public server is remote, at mcp.agentik-os.com/api/mcp. OAuth proves who you are. A paid plan, or an official OS you already unlocked, is what can() checks before a tool runs. - [Mechanistic interpretability](https://agentik-os.com/glossary/mechanistic-interpretability): Mechanistic interpretability is a research approach that tries to reverse engineer neural networks into understandable components, identifying the specific neurons, features and circuits that implement a model's behaviors. - [Membership inference attack](https://agentik-os.com/glossary/membership-inference-attack): A membership inference attack is a privacy attack that tries to determine whether a specific record was part of a model's training data by analyzing how the model responds to it. - [MemGPT](https://agentik-os.com/glossary/memgpt): MemGPT is a research system that manages an agent's memory like an operating system manages virtual memory, moving information between the limited context window and external storage as needed. - [Memory consolidation](https://agentik-os.com/glossary/memory-consolidation): Memory consolidation, in AI agents, is the background process that turns raw conversation logs into compact long-term memories by extracting facts, merging duplicates, and summarizing, borrowing the idea from how human memory stabilizes. - [Memory decay](https://agentik-os.com/glossary/memory-decay): Memory decay is a mechanism by which an agent's stored memories lose weight or are removed over time or with disuse, keeping memory stores relevant and preventing outdated information from dominating. - [Memory store](https://agentik-os.com/glossary/memory-store): A memory store is the storage backend, such as a database, vector store or file system, where an AI agent saves memories so they can be searched and retrieved in later sessions. - [Message broker](https://agentik-os.com/glossary/message-broker): A message broker is middleware that receives, stores and routes messages between applications, handling queues or topics, delivery guarantees and acknowledgements on their behalf. - [Message queue](https://agentik-os.com/glossary/message-queue): A message queue is a component that stores messages between services until they are processed, letting systems handle work asynchronously, absorb traffic spikes and retry failed tasks. - [Message roles](https://agentik-os.com/glossary/message-roles): Message roles are labels such as system, user and assistant attached to each message in a chat conversation, telling the model who wrote each part and how much authority its instructions carry. - [Meta-prompting](https://agentik-os.com/glossary/meta-prompting): Meta-prompting is using a language model to write, critique or improve prompts, or structuring a prompt so the model reasons about how to approach a task before performing it. - [Metadata filtering](https://agentik-os.com/glossary/metadata-filtering): Metadata filtering is restricting search results using structured attributes attached to documents, such as date, author, source or access rights, either before or alongside similarity search. - [Min-p sampling](https://agentik-os.com/glossary/min-p-sampling): Min-p sampling is a text generation method that keeps only tokens whose probability is at least a set fraction of the most likely token's probability, adapting the candidate pool to the model's confidence. - [Mistral](https://agentik-os.com/glossary/mistral): Mistral refers to the large language models developed by the French company Mistral AI, which include both open-weight models and commercially licensed models. - [Mixture of agents](https://agentik-os.com/glossary/mixture-of-agents): Mixture of agents is a technique in which several language models answer the same prompt, later layers of models refine those answers using the earlier ones as input, and a final aggregator model combines them into one response. - [Mixture of experts](https://agentik-os.com/glossary/mixture-of-experts): Mixture of experts is a model architecture that contains many specialized subnetworks, called experts, and a router that activates only a few of them for each token, increasing capacity without proportional compute. - [MLOps](https://agentik-os.com/glossary/mlops): MLOps is the set of practices and tools for reliably deploying, monitoring and maintaining machine learning models in production, applying DevOps principles such as automation, versioning and continuous delivery. - [MMLU](https://agentik-os.com/glossary/mmlu): MMLU is a widely used benchmark of multiple-choice questions spanning dozens of subjects, such as law, medicine and mathematics, used to measure a language model's general knowledge and reasoning. - [Model card](https://agentik-os.com/glossary/model-card): A model card is a short document published with a machine learning model that describes its intended uses, training data, evaluation results, limitations and known risks, helping users judge whether it fits their purpose. - [Model collapse](https://agentik-os.com/glossary/model-collapse): Model collapse is a degradation that can occur when models are trained repeatedly on data generated by other models, gradually losing diversity and accuracy compared with training on human data. - [Model Context Protocol](https://agentik-os.com/glossary/model-context-protocol): The Model Context Protocol is the control plane a host uses to call tools. Agentik is a remote MCP server at https://mcp.agentik-os.com/api/mcp. Claude, Claude Code, Cursor, ChatGPT, Codex, and Hermes each add that same URL. The marketing site does not serve the call. - [Model extraction](https://agentik-os.com/glossary/model-extraction): Model extraction is an attack in which someone repeatedly queries a model's API to reconstruct a close copy of the model or recover its behavior, threatening intellectual property and security. - [Model inversion attack](https://agentik-os.com/glossary/model-inversion-attack): A model inversion attack is a privacy attack that uses a model's outputs to reconstruct sensitive information about its training data, such as recovering features of individuals it learned from. - [Model merging](https://agentik-os.com/glossary/model-merging): Model merging is a technique that combines the weights of two or more fine-tuned models into a single model, aiming to keep the strengths of each without additional training. - [Model parallelism](https://agentik-os.com/glossary/model-parallelism): Model parallelism is splitting a single model across multiple GPUs or machines, either by dividing its layers or its individual tensor operations, so models too large for one device can be trained or served. - [Model registry](https://agentik-os.com/glossary/model-registry): A model registry is a central store that tracks trained models and their versions, metadata, evaluation results and approval status, serving as the source of truth for what gets deployed. - [Model risk management](https://agentik-os.com/glossary/model-risk-management): Model risk management is the discipline of identifying, validating, monitoring and controlling the risks of relying on models for decisions, long established in banking and increasingly applied to AI systems. - [Model serving](https://agentik-os.com/glossary/model-serving): Model serving is the infrastructure and software that host a trained model and expose it to applications, usually through an API, handling requests, scaling, batching and monitoring in production. - [Monitoring](https://agentik-os.com/glossary/monitoring): Monitoring is the continuous collection and review of metrics about a running system, such as errors, latency, cost and output quality, with alerts when values move outside expected ranges. - [Multi-agent conversation](https://agentik-os.com/glossary/multi-agent-conversation): A multi-agent conversation is a coordination style in which several agents exchange messages in a shared thread, taking turns to contribute until the task is solved or a stop condition is met. - [Multi-agent debate](https://agentik-os.com/glossary/multi-agent-debate): Multi-agent debate is a technique in which several model instances propose answers, critique each other's reasoning over several rounds and converge on a final answer, often to improve accuracy. - [Multi-agent system](https://agentik-os.com/glossary/multi-agent-system): A multi-agent system is more than one agent on the same line of work. Without an operating system they forget each other's constraint. Agentik is that system. Content, Growth, and Librarian are specialized lines, not a pile of bots in separate tabs. Decision is retired. - [Multi-head attention](https://agentik-os.com/glossary/multi-head-attention): Multi-head attention runs several attention operations in parallel, each learning to focus on different relationships in the data, then combines their outputs. It is a core component of transformers. - [Multi-hop retrieval](https://agentik-os.com/glossary/multi-hop-retrieval): Multi-hop retrieval is answering a question that requires combining facts from several documents by retrieving iteratively, where information found in one step guides the search in the next. - [Multi-query retrieval](https://agentik-os.com/glossary/multi-query-retrieval): Multi-query retrieval is generating several differently worded versions of a question, retrieving results for each and combining them, which reduces the chance that one phrasing misses relevant documents. - [Multi-tenancy](https://agentik-os.com/glossary/multi-tenancy): Multi-tenancy is an architecture in which one instance of a system serves multiple customers or workspaces while keeping each tenant's data, configuration and access strictly separated. - [Multi-turn conversation](https://agentik-os.com/glossary/multi-turn-conversation): A multi-turn conversation is an exchange with a language model spanning several back-and-forth messages, where later responses depend on what was said earlier in the same session. - [Multimodal agent](https://agentik-os.com/glossary/multimodal-agent): A multimodal agent is an AI agent that can perceive and work with more than one type of input or output, such as text, images, audio and video, when planning and taking actions. - [Multimodal model](https://agentik-os.com/glossary/multimodal-model): A multimodal model is an AI model that can process and often generate more than one type of data, such as text, images, audio, and video, within a single system. - [Multimodal prompting](https://agentik-os.com/glossary/multimodal-prompting): Multimodal prompting is giving a model instructions that combine several kinds of input, such as text with images, audio or documents, so it can reason across them in one request. - [Multimodal RAG](https://agentik-os.com/glossary/multimodal-rag): Multimodal RAG is retrieval-augmented generation over sources that include images, tables, audio or video as well as text, retrieving the relevant items and passing them to a multimodal model. - [Natural language processing](https://agentik-os.com/glossary/natural-language-processing): Natural language processing is the field of AI concerned with enabling computers to understand, interpret, and generate human language in text or speech. - [Negative prompt](https://agentik-os.com/glossary/negative-prompt): A negative prompt is text that tells a generative model, most often an image generator, what to avoid in its output, such as unwanted objects, styles or artifacts. - [Negotiation](https://agentik-os.com/glossary/negotiation): Negotiation in multi-agent systems is a process in which agents with different goals or resources exchange proposals and counterproposals to reach an agreement acceptable to all parties. - [Neural network](https://agentik-os.com/glossary/neural-network): A neural network is a computational model made of layers of interconnected units that transform input data through learned weights, loosely inspired by how neurons in the brain pass signals to one another. - [Next-token prediction](https://agentik-os.com/glossary/next-token-prediction): Next-token prediction is the training objective in which a language model learns to predict the most likely next token given all the tokens before it. Repeating this step generates text. - [NIST AI Risk Management Framework](https://agentik-os.com/glossary/nist-ai-risk-management-framework): The NIST AI Risk Management Framework is voluntary guidance from the US National Institute of Standards and Technology that helps organizations identify, measure and manage AI risks through its govern, map, measure and manage functions. - [NPU](https://agentik-os.com/glossary/npu): An NPU is a specialized processor built into many phones, laptops and edge devices to run neural network workloads efficiently with low power consumption. - [OAuth](https://agentik-os.com/glossary/oauth): OAuth is an open standard for delegated authorization that lets a user grant an application limited access to their account on another service without sharing their password, using scoped access tokens. - [Observability](https://agentik-os.com/glossary/observability): Observability is the ability to understand what a system is doing from the data it emits, such as logs, metrics and traces, and for AI systems also includes prompts, outputs, costs and tool calls. - [Observation](https://agentik-os.com/glossary/observation): An observation is the information an agent receives back after taking an action, such as a tool result, command output, error message or screenshot, which it uses to decide what to do next. - [Offline evaluation](https://agentik-os.com/glossary/offline-evaluation): Offline evaluation is the testing of an AI system on fixed, prepared datasets before or outside of production, allowing controlled comparisons between models, prompts or versions without affecting real users. - [Ollama](https://agentik-os.com/glossary/ollama): Ollama is an open-source tool for downloading and running large language models locally on a personal computer or server, offering a simple command line interface and a local API. - [On-premise](https://agentik-os.com/glossary/on-premise): On-premise refers to running software and AI models on hardware an organization owns and operates in its own facilities, rather than in a public cloud, giving more control over data and infrastructure. - [One-shot prompting](https://agentik-os.com/glossary/one-shot-prompting): One-shot prompting is giving a language model a single worked example of the desired input and output before the real task, so it can infer the expected format and behavior. - [Online evaluation](https://agentik-os.com/glossary/online-evaluation): Online evaluation is the measurement of an AI system's quality using live production traffic, such as user feedback, A/B tests or automated scoring of real interactions. - [ONNX](https://agentik-os.com/glossary/onnx): ONNX is an open format for representing machine learning models so they can be moved between frameworks and run on different hardware using compatible runtimes such as ONNX Runtime. - [Ontology](https://agentik-os.com/glossary/ontology): An ontology is a formal specification of the types of entities, properties and relationships in a domain, defining the vocabulary and rules that a knowledge graph or data model follows. - [Open-domain question answering](https://agentik-os.com/glossary/open-domain-question-answering): Open-domain question answering is answering questions on any topic by first retrieving relevant passages from a large collection, such as an encyclopedia or the web, and then producing an answer from them. - [Open-weight model](https://agentik-os.com/glossary/open-weight-model): An open-weight model is a model whose trained weights are publicly released for download, allowing anyone to run or fine-tune it, even if its training data and code are not published. - [OpenAI-compatible API](https://agentik-os.com/glossary/openai-compatible-api): An OpenAI-compatible API is an interface that mirrors the request and response format of OpenAI's API, letting applications switch between model providers or self-hosted servers with minimal code changes. - [OpenAPI tool](https://agentik-os.com/glossary/openapi-tool): An OpenAPI tool is a tool generated from an OpenAPI specification, which describes a web API's endpoints and parameters, allowing an agent to call that API without hand-written tool definitions. - [OpenTelemetry](https://agentik-os.com/glossary/opentelemetry): OpenTelemetry is an open-source, vendor-neutral standard and toolkit for generating and collecting traces, metrics and logs, increasingly used to instrument AI applications and model calls. - [Optimizer](https://agentik-os.com/glossary/optimizer): An optimizer is the algorithm that decides how to update a model's parameters from computed gradients during training. Common examples include stochastic gradient descent and Adam. - [Orchestrator-worker pattern](https://agentik-os.com/glossary/orchestrator-worker-pattern): The orchestrator-worker pattern is a design in which a central orchestrator breaks a task into subtasks at run time, sends them to worker agents or model calls, and combines their results. - [Output parser](https://agentik-os.com/glossary/output-parser): An output parser is code that converts a language model's text response into structured data, such as an object or list, and often validates it or requests a retry when parsing fails. - [Output token](https://agentik-os.com/glossary/output-token): An output token is a token the language model generates in its response. Output tokens are produced one at a time, so they drive generation time and are often priced higher than input tokens. - [Output validation](https://agentik-os.com/glossary/output-validation): Output validation is the checking of an AI model's response before it is used, for example confirming it matches a required schema, contains no unsafe content and stays within allowed values. - [Over-refusal](https://agentik-os.com/glossary/over-refusal): Over-refusal is when an AI model declines harmless requests because they superficially resemble harmful ones, making the system less useful without making it any safer. - [Overfitting](https://agentik-os.com/glossary/overfitting): Overfitting happens when a model learns the training data too closely, including its noise, so it performs well on that data but poorly on new, unseen examples. - [OWASP Top 10 for LLM Applications](https://agentik-os.com/glossary/owasp-top-10-for-llm-applications): The OWASP Top 10 for LLM Applications is a list published by the Open Worldwide Application Security Project that ranks the most critical security risks in applications built on large language models, such as prompt injection. - [PagedAttention](https://agentik-os.com/glossary/pagedattention): PagedAttention is a memory management technique for the KV cache, introduced with vLLM, that stores attention data in fixed-size blocks like virtual memory pages to reduce waste and serve more requests at once. - [Parallel tool calling](https://agentik-os.com/glossary/parallel-tool-calling): Parallel tool calling is the ability of a model to request several independent tool calls in a single turn so they can be executed at the same time, reducing the number of round trips needed. - [Parallelization](https://agentik-os.com/glossary/parallelization): Parallelization is a workflow pattern in which several model calls run at the same time, either on different parts of a task or on the same task to compare answers, and their outputs are then combined. - [Parameter](https://agentik-os.com/glossary/parameter): A parameter is a value inside a model, such as a weight or bias, that is learned from data during training. The total number of parameters is often used as a rough measure of model size. - [Parameter count](https://agentik-os.com/glossary/parameter-count): Parameter count is the total number of learned weights in a model, often expressed in billions. It is a common but imperfect indicator of a model's size, cost, and capability. - [Parameter-efficient fine-tuning](https://agentik-os.com/glossary/parameter-efficient-fine-tuning): Parameter-efficient fine-tuning is a family of methods that adapt a large model by training only a small number of added or selected parameters, greatly reducing memory and compute costs. - [Parent document retrieval](https://agentik-os.com/glossary/parent-document-retrieval): Parent document retrieval is a strategy that searches over small, precise chunks but returns the larger passage or document they belong to, giving the model fuller context for its answer. - [Pass@k](https://agentik-os.com/glossary/pass-k): Pass@k is a code evaluation metric giving the probability that at least one of k generated solutions to a problem passes its tests, commonly reported as pass@1 for single attempts. - [Perceptron](https://agentik-os.com/glossary/perceptron): A perceptron is one of the earliest neural network models, a single artificial neuron that learns a linear boundary to separate inputs into two classes. It is the building block of multilayer networks. - [Personally identifiable information](https://agentik-os.com/glossary/personally-identifiable-information): Personally identifiable information is any data that can identify a specific individual, directly or when combined with other data, such as a name, email address, phone number or government ID number. - [pgvector](https://agentik-os.com/glossary/pgvector): pgvector is an open-source extension for the PostgreSQL database that adds a vector data type, similarity operators and approximate nearest neighbor indexes, allowing embeddings to be stored alongside relational data. - [PII redaction](https://agentik-os.com/glossary/pii-redaction): PII redaction is the process of detecting and removing or masking personally identifiable information, such as names, addresses or ID numbers, from text or data before it is stored, logged or sent to an AI model. - [Pipeline](https://agentik-os.com/glossary/pipeline): A pipeline is a series of processing stages in which the output of each stage becomes the input of the next, used to move data or tasks through steps such as extraction, model calls and validation. - [Plan-and-execute](https://agentik-os.com/glossary/plan-and-execute): Plan-and-execute is an agent design in which a model first writes a complete multi-step plan and then a separate executor carries out each step, with the option to revise the plan as results come in. - [Plan-and-solve prompting](https://agentik-os.com/glossary/plan-and-solve-prompting): Plan-and-solve prompting is a technique that instructs a language model to first devise a plan that splits a task into steps and then carry out those steps, reducing skipped or missing reasoning. - [Planner](https://agentik-os.com/glossary/planner): A planner is the component of an agent system that turns a goal into an ordered set of steps or subtasks before or during execution, often implemented as a dedicated model call or a separate agent. - [Plugin](https://agentik-os.com/glossary/plugin): A plugin is an add-on package that extends an AI application or agent with new tools, integrations, commands or instructions, usually installed without changing the core software. - [Policy](https://agentik-os.com/glossary/policy): In reinforcement learning, a policy is the strategy an agent uses to choose actions given its current situation. Training aims to find a policy that maximizes expected reward. - [Positional encoding](https://agentik-os.com/glossary/positional-encoding): Positional encoding is information added to token representations in a transformer to indicate each token's position in the sequence, since attention alone does not capture word order. - [PPO](https://agentik-os.com/glossary/ppo): PPO, or proximal policy optimization, is a reinforcement learning algorithm that makes limited, stable updates to a policy at each step. It has been widely used in RLHF for language models. - [Precision](https://agentik-os.com/glossary/precision): Precision is an evaluation metric measuring the share of a model's positive predictions that are actually correct, answering how many of the items it flagged were right. - [Prefill](https://agentik-os.com/glossary/prefill): Prefill is the technique of writing the first part of the model's response in advance, such as an opening brace, so the model continues from that point in the desired format or direction. - [Pretraining](https://agentik-os.com/glossary/pretraining): Pretraining is the first and most compute-intensive stage of building a foundation model, in which it learns general patterns from very large unlabeled datasets, usually by predicting the next token. - [Priority queue](https://agentik-os.com/glossary/priority-queue): A priority queue is a queue in which each item has a priority and higher-priority items are processed first, used to make urgent tasks overtake routine ones. - [Procedural memory](https://agentik-os.com/glossary/procedural-memory): Procedural memory in AI agents is stored knowledge of how to perform tasks, such as instructions, learned workflows or reusable skills, that shapes how the agent acts rather than what it knows. - [Product quantization](https://agentik-os.com/glossary/product-quantization): Product quantization is a vector compression technique that splits each vector into sub-vectors and replaces each with the ID of its nearest representative, greatly reducing memory for large-scale similarity search. - [Program-aided language model](https://agentik-os.com/glossary/program-aided-language-model): A program-aided language model is an approach in which the model writes code, such as Python, to represent its reasoning, and an interpreter runs that code to compute the final answer precisely. - [Prompt](https://agentik-os.com/glossary/prompt): A prompt is the input text, and sometimes images or other data, given to a language model to tell it what to do. It can include instructions, examples, context and questions that shape the response. - [Prompt caching](https://agentik-os.com/glossary/prompt-caching): Prompt caching is reusing the processed form of a repeated prompt prefix, such as a long system prompt or document, across requests so later calls are faster and usually cheaper. - [Prompt chaining](https://agentik-os.com/glossary/prompt-chaining): Prompt chaining is a workflow pattern that splits a task into a fixed sequence of model calls, where each call processes the output of the previous one, often with checks between steps. - [Prompt compression](https://agentik-os.com/glossary/prompt-compression): Prompt compression is shortening a prompt while keeping its essential meaning, often by removing low-information tokens or rewriting content concisely, to lower cost and latency. - [Prompt engineering](https://agentik-os.com/glossary/prompt-engineering): Prompt engineering is the practice of designing and refining the instructions, examples and context given to a language model so that it produces more accurate, useful and consistent outputs for a task. - [Prompt injection](https://agentik-os.com/glossary/prompt-injection): Prompt injection is an attack in which crafted text causes a language model to ignore its original instructions and follow the attacker's instead, for example to leak data or take unintended actions. - [Prompt library](https://agentik-os.com/glossary/prompt-library): A prompt library is a curated, shared collection of tested prompts and templates that a person or team reuses for recurring tasks instead of writing new prompts from scratch. - [Prompt optimization](https://agentik-os.com/glossary/prompt-optimization): Prompt optimization is the systematic, often automated, improvement of prompts by testing variations against examples or metrics and keeping the versions that perform best on a task. - [Prompt sensitivity](https://agentik-os.com/glossary/prompt-sensitivity): Prompt sensitivity is the tendency of a language model to give noticeably different outputs when a prompt is changed in small ways, such as rewording, reordering examples or altering formatting. - [Prompt template](https://agentik-os.com/glossary/prompt-template): A prompt template is a reusable prompt with placeholders, such as a user question or retrieved documents, that are filled in at run time so the same structure can serve many inputs. - [Prompt versioning](https://agentik-os.com/glossary/prompt-versioning): Prompt versioning is the practice of tracking changes to prompts over time, like code, so teams can compare versions, roll back regressions and know which prompt produced a given output. - [Proprietary model](https://agentik-os.com/glossary/proprietary-model): A proprietary model is an AI model whose weights are not publicly released and which is typically accessed only through the developer's application or API. - [Pruning](https://agentik-os.com/glossary/pruning): Pruning is a model compression technique that removes weights, neurons, or entire components that contribute little to a model's output, making the model smaller and faster. - [Publish-subscribe](https://agentik-os.com/glossary/publish-subscribe): Publish-subscribe is a messaging pattern in which senders publish messages to named topics and any number of subscribers receive the messages for topics they have registered for, without knowing each other. - [QLoRA](https://agentik-os.com/glossary/qlora): QLoRA is a fine-tuning method that combines LoRA with a quantized base model, allowing large language models to be fine-tuned with much less GPU memory. - [Quantization](https://agentik-os.com/glossary/quantization): Quantization is a technique that stores a model's weights, and sometimes activations, with lower numerical precision, such as 8-bit or 4-bit numbers, reducing memory use and speeding up inference. - [Query expansion](https://agentik-os.com/glossary/query-expansion): Query expansion is adding related terms, synonyms or alternative phrasings to a search query so that retrieval finds relevant documents that use different wording from the original query. - [Query rewriting](https://agentik-os.com/glossary/query-rewriting): Query rewriting is transforming a user's query, often with a language model, into a clearer or more search-friendly form, for example by resolving references to earlier conversation or fixing vague wording. - [Query routing](https://agentik-os.com/glossary/query-routing): Query routing is directing each query to the most suitable data source, index or retrieval method, such as a vector store, a SQL database or web search, based on its content. - [Qwen](https://agentik-os.com/glossary/qwen): Qwen is a family of large language and multimodal models developed by Alibaba Cloud, many of which are released with open weights in a range of sizes. - [Race condition](https://agentik-os.com/glossary/race-condition): A race condition is a bug that occurs when the outcome depends on the unpredictable timing of concurrent operations, such as two agents updating the same file or record at the same time. - [RAPTOR](https://agentik-os.com/glossary/raptor): RAPTOR is a retrieval method that clusters and recursively summarizes document chunks into a tree of summaries, letting a system retrieve at different levels of detail, from specific passages to high-level overviews. - [ReAct](https://agentik-os.com/glossary/react): ReAct is an agent prompting pattern in which a language model alternates between writing reasoning steps and taking actions such as tool calls, using each observation to inform its next thought and action. - [Reactive agent](https://agentik-os.com/glossary/reactive-agent): A reactive agent is an agent that responds directly to its current perceptions using fixed rules or learned mappings, without building an internal model of the world or planning ahead. - [Reasoning model](https://agentik-os.com/glossary/reasoning-model): A reasoning model is a language model trained to work through problems step by step, often generating intermediate reasoning before its final answer, which improves results on math, coding, and logic tasks. - [Reasoning tokens](https://agentik-os.com/glossary/reasoning-tokens): Reasoning tokens are tokens a model generates while working through a problem before producing its final answer. They consume context and compute and may be hidden from or summarized for the user. - [Recall](https://agentik-os.com/glossary/recall): Recall is an evaluation metric measuring the share of all actual positive cases that a model correctly identifies, answering how many of the relevant items it managed to find. - [Reciprocal rank fusion](https://agentik-os.com/glossary/reciprocal-rank-fusion): Reciprocal rank fusion is a method for merging ranked result lists from different search systems by scoring each item based on its rank positions, commonly used to combine keyword and vector search results. - [Recurrent neural network](https://agentik-os.com/glossary/recurrent-neural-network): A recurrent neural network is a neural network that processes sequences step by step while carrying a hidden state forward, letting earlier inputs influence later ones. Transformers have largely replaced it for language. - [Red teaming](https://agentik-os.com/glossary/red-teaming): Red teaming is the practice of deliberately attacking an AI system, often with specialized testers, to uncover harmful outputs, security weaknesses and failure modes before real users or attackers find them. - [Reflection](https://agentik-os.com/glossary/reflection): Reflection is a technique in which an agent reviews its own previous output, actions or failures, writes down what went wrong or could improve, and uses that analysis to guide its next attempt. - [Reflexion](https://agentik-os.com/glossary/reflexion): Reflexion is an agent framework in which an agent turns feedback from failed attempts into written self-reflections, stores them in memory and reads them on later attempts to improve without retraining the model. - [Refusal](https://agentik-os.com/glossary/refusal): A refusal is when an AI model declines to fulfill a request, typically because it judges the request harmful, against policy or outside its capabilities, ideally with a brief explanation. - [Regression](https://agentik-os.com/glossary/regression): Regression is a machine learning task in which a model predicts a continuous numerical value, such as a house price or tomorrow's temperature, from input features. - [Regression test](https://agentik-os.com/glossary/regression-test): A regression test is a check rerun after a change, such as a new prompt, model or code version, to confirm that behavior which previously worked has not degraded. - [Regularization](https://agentik-os.com/glossary/regularization): Regularization is any technique that discourages a model from becoming overly complex, such as penalizing large weights or randomly disabling units, in order to reduce overfitting and improve generalization. - [Reinforcement learning](https://agentik-os.com/glossary/reinforcement-learning): Reinforcement learning is a machine learning approach in which an agent learns by acting in an environment and receiving rewards or penalties, gradually discovering behavior that maximizes long-term reward. - [Reinforcement learning with verifiable rewards](https://agentik-os.com/glossary/reinforcement-learning-with-verifiable-rewards): Reinforcement learning with verifiable rewards is a training approach in which a model is rewarded based on automatically checkable outcomes, such as a correct math answer or passing code tests. - [Relevance feedback](https://agentik-os.com/glossary/relevance-feedback): Relevance feedback is an information retrieval technique that uses judgments about which results were relevant, from users or automatically, to refine the query and improve subsequent results. - [ReLU](https://agentik-os.com/glossary/relu): ReLU, or rectified linear unit, is a widely used activation function that outputs its input when positive and zero otherwise. Its simplicity makes deep networks faster and easier to train. - [Repetition penalty](https://agentik-os.com/glossary/repetition-penalty): A repetition penalty is a generation setting that lowers the probability of tokens that have already appeared, discouraging a language model from repeating words or phrases. - [Replanning](https://agentik-os.com/glossary/replanning): Replanning is the revision of an agent's or workflow's plan during execution when new information, failures or changed goals show that the original plan will not work as intended. - [Reranking](https://agentik-os.com/glossary/reranking): Reranking is a second retrieval stage in which a more accurate but slower model reorders an initial set of candidate results by relevance to the query before they are shown or passed to a model. - [Residual connection](https://agentik-os.com/glossary/residual-connection): A residual connection is a shortcut that adds a layer's input directly to its output, letting information and gradients bypass the layer. It makes very deep networks, including transformers, much easier to train. - [Responsible AI](https://agentik-os.com/glossary/responsible-ai): Responsible AI is an approach to designing, building and deploying AI systems that emphasizes fairness, transparency, privacy, safety, accountability and human oversight throughout the system's lifecycle. - [REST API](https://agentik-os.com/glossary/rest-api): A REST API is a web interface that follows the REST architectural style, exposing resources at URLs that clients read and modify using standard HTTP methods such as GET and POST. - [Retrieval-augmented generation](https://agentik-os.com/glossary/retrieval-augmented-generation): Retrieval-augmented generation is a technique that fetches relevant documents from an external source and adds them to a language model's prompt, so answers draw on up-to-date or private information beyond its training data. - [Retriever](https://agentik-os.com/glossary/retriever): A retriever is the component of a search or RAG system that takes a query and returns the most relevant documents or passages from a collection, using keyword matching, vector similarity or both. - [Retry with backoff](https://agentik-os.com/glossary/retry-with-backoff): Retry with backoff is a strategy of retrying a failed operation after progressively longer waits, often doubling the delay and adding randomness, so temporary failures can recover without overloading the service. - [Reward function](https://agentik-os.com/glossary/reward-function): A reward function defines the numerical feedback an agent receives for its actions in reinforcement learning. It encodes what counts as success and therefore shapes the behavior the agent learns. - [Reward hacking](https://agentik-os.com/glossary/reward-hacking): Reward hacking is when an AI system finds an unintended shortcut to maximize its reward or score, satisfying the literal objective while failing to achieve what its designers actually wanted. - [Reward model](https://agentik-os.com/glossary/reward-model): A reward model is a model trained to score outputs according to human or AI preferences. It supplies the feedback signal used to optimize a language model during reinforcement learning. - [RLAIF](https://agentik-os.com/glossary/rlaif): RLAIF, or reinforcement learning from AI feedback, is a variant of RLHF in which preference judgments used to train the model are generated by an AI model instead of human raters. - [RLHF](https://agentik-os.com/glossary/rlhf): RLHF, or reinforcement learning from human feedback, is a training method in which humans rank model outputs, a reward model learns those preferences, and the language model is optimized to score well on it. - [Robotic process automation](https://agentik-os.com/glossary/robotic-process-automation): Robotic process automation is software that automates repetitive, rule-based computer tasks by mimicking user actions in applications, such as copying data between systems, following scripts rather than reasoning like an AI agent. - [Robustness](https://agentik-os.com/glossary/robustness): Robustness is an AI system's ability to keep performing correctly when inputs are noisy, unusual, rephrased or adversarial, rather than failing on small changes to the data it sees. - [Role prompting](https://agentik-os.com/glossary/role-prompting): Role prompting is instructing a language model to adopt a specific role or persona, such as a lawyer or teacher, to steer its vocabulary, level of detail and point of view. - [Role-based access control](https://agentik-os.com/glossary/role-based-access-control): Role-based access control is a method of managing permissions by assigning them to roles, such as viewer or administrator, and then assigning users, services or agents to those roles. - [Role-based agents](https://agentik-os.com/glossary/role-based-agents): Role-based agents are a multi-agent design in which each agent is given a defined role, such as researcher, writer or reviewer, with its own instructions and tools, and the roles work together on a task. - [Rollback](https://agentik-os.com/glossary/rollback): A rollback is reverting a system to a previous known-good version of its code, model, prompt or configuration after a release causes errors or degraded quality. - [Rotary position embedding](https://agentik-os.com/glossary/rotary-position-embedding): Rotary position embedding is a method for encoding token positions in a transformer by rotating query and key vectors, helping models handle relative positions. It is widely used in modern language models. - [ROUGE](https://agentik-os.com/glossary/rouge): ROUGE is a family of automatic metrics that evaluate generated text, especially summaries, by measuring the overlap of words and word sequences with human-written reference texts. - [Round-robin scheduling](https://agentik-os.com/glossary/round-robin-scheduling): Round-robin scheduling is a method that gives each participant, such as a worker or agent, a turn in a fixed rotating order, used to share work evenly or decide who speaks next. - [Routing](https://agentik-os.com/glossary/routing): Routing is the step in an AI system that classifies an incoming request and sends it to the most suitable handler, such as a specialized agent, prompt, tool or model. - [Safety evaluation](https://agentik-os.com/glossary/safety-evaluation): A safety evaluation is a test that measures whether an AI model can produce harmful outputs or has dangerous capabilities, such as assisting cyberattacks, used to decide what safeguards are needed before release. - [Sampling](https://agentik-os.com/glossary/sampling): Sampling is the process of choosing each next token randomly according to the model's predicted probabilities, often shaped by settings such as temperature, top-p, and top-k. - [Sandbox](https://agentik-os.com/glossary/sandbox): A sandbox is an isolated execution environment, such as a container or virtual machine, where an agent can run code or commands without being able to affect the host system, other users or sensitive data. - [Scaling laws](https://agentik-os.com/glossary/scaling-laws): Scaling laws are empirical relationships showing that a model's performance improves predictably as model size, training data, and compute increase, used to plan how large models should be trained. - [Scheduler](https://agentik-os.com/glossary/scheduler): A scheduler is a component that starts tasks or workflows at set times or intervals, or when resources become available, such as running an agent every morning. - [Scratchpad](https://agentik-os.com/glossary/scratchpad): A scratchpad is a space in a prompt or output where a language model writes intermediate working, such as calculations or reasoning notes, before giving its final answer. - [Secrets management](https://agentik-os.com/glossary/secrets-management): Secrets management is the secure storage, distribution, rotation and auditing of sensitive credentials such as API keys, passwords and tokens, keeping them out of source code and logs. - [Self-ask prompting](https://agentik-os.com/glossary/self-ask-prompting): Self-ask prompting is a technique in which a language model explicitly poses and answers its own follow-up questions before answering the original question, which helps with questions that combine several facts. - [Self-attention](https://agentik-os.com/glossary/self-attention): Self-attention is a form of attention in which each element of a sequence, such as a token, looks at all other elements of the same sequence to decide which ones matter for its meaning. - [Self-consistency](https://agentik-os.com/glossary/self-consistency): Self-consistency is a prompting technique that samples several independent reasoning paths for the same question and selects the answer that appears most often, reducing the impact of any single flawed chain of reasoning. - [Self-critique](https://agentik-os.com/glossary/self-critique): Self-critique is a technique in which a model evaluates its own draft answer against criteria or instructions, points out errors or weaknesses, and then produces a revised version that addresses them. - [Self-debugging](https://agentik-os.com/glossary/self-debugging): Self-debugging is a technique in which a model runs or inspects the code it wrote, reads error messages or test results, explains the problem to itself and then repairs the code in further iterations. - [Self-hosting](https://agentik-os.com/glossary/self-hosting): Self-hosting is running an AI model on infrastructure you control, whether on-premise or in your own cloud account, rather than calling a third-party model provider's API. - [Self-RAG](https://agentik-os.com/glossary/self-rag): Self-RAG is a retrieval-augmented generation method in which the model decides when retrieval is needed and critiques the retrieved passages and its own output using special reflection tokens. - [Self-refine](https://agentik-os.com/glossary/self-refine): Self-refine is a technique in which a language model critiques its own output and then rewrites it based on that feedback, repeating the cycle to improve quality without additional training. - [Self-supervised learning](https://agentik-os.com/glossary/self-supervised-learning): Self-supervised learning is a training approach in which a model creates its own learning signal from unlabeled data, such as predicting a hidden word from its context. It underpins modern language model pretraining. - [Semantic cache](https://agentik-os.com/glossary/semantic-cache): A semantic cache stores previous model responses and returns a saved answer when a new query is similar enough in meaning to an earlier one, reducing cost and latency for repeated questions. - [Semantic chunking](https://agentik-os.com/glossary/semantic-chunking): Semantic chunking is splitting text at points where the meaning shifts, often detected by comparing embeddings of neighboring sentences, rather than at fixed character or token counts. - [Semantic Kernel](https://agentik-os.com/glossary/semantic-kernel): Semantic Kernel is an open-source software development kit from Microsoft for integrating language models into applications, letting developers expose code as plugins that models and agents can call. - [Semantic memory](https://agentik-os.com/glossary/semantic-memory): Semantic memory in AI agents is stored general knowledge and facts, such as information about a user, a domain or an organization, kept independent of when or how it was learned. - [Semantic search](https://agentik-os.com/glossary/semantic-search): Semantic search is search that matches the meaning and intent of a query rather than only its exact words, typically by comparing embeddings, so relevant results can appear even without shared keywords. - [Semi-supervised learning](https://agentik-os.com/glossary/semi-supervised-learning): Semi-supervised learning is a machine learning approach that combines a small amount of labeled data with a larger amount of unlabeled data to train a model more efficiently. - [Sensitive information disclosure](https://agentik-os.com/glossary/sensitive-information-disclosure): Sensitive information disclosure is when an AI system reveals confidential data, such as personal details, credentials or proprietary content, from its training data, context or connected tools to people who should not see it. - [Sentence embedding](https://agentik-os.com/glossary/sentence-embedding): A sentence embedding is a single vector representing the meaning of a whole sentence or passage, produced by a model trained so that sentences with similar meanings have nearby vectors. - [SentencePiece](https://agentik-os.com/glossary/sentencepiece): SentencePiece is an open-source tokenization library that learns subword units directly from raw text, treating spaces as ordinary symbols, which makes it language independent and widely used in multilingual models. - [Server-sent events](https://agentik-os.com/glossary/server-sent-events): Server-sent events is a web standard that lets a server push a continuous stream of messages to a client over a single HTTP connection, commonly used to stream language model responses. - [Serverless](https://agentik-os.com/glossary/serverless): Serverless is a cloud model in which the provider runs code or models on demand and manages all servers, billing only for actual usage, often with automatic scaling down to zero. - [Service level agreement](https://agentik-os.com/glossary/service-level-agreement): A service level agreement is a contract that defines the level of service a provider commits to, such as uptime and response times, and the remedies if those targets are missed. - [Shadow AI](https://agentik-os.com/glossary/shadow-ai): Shadow AI is the use of AI tools and services by employees without the approval or oversight of their organization's IT or security teams, creating hidden risks around data exposure and compliance. - [Shadow deployment](https://agentik-os.com/glossary/shadow-deployment): A shadow deployment runs a new model alongside the current one on real traffic, recording its outputs for comparison without showing them to users, so it can be evaluated safely. - [Shared state](https://agentik-os.com/glossary/shared-state): Shared state is data that several agents or workflow steps can read and update, such as a task list or conversation record, which lets them coordinate but requires care to avoid conflicting changes. - [Short-term memory](https://agentik-os.com/glossary/short-term-memory): Short-term memory in AI agents is information kept only for the current task or session, usually held directly in the model's context window, and lost when the session ends unless saved elsewhere. - [Sliding context window](https://agentik-os.com/glossary/sliding-context-window): A sliding context window is a strategy that keeps only the most recent part of a conversation or document in the model's context, dropping older content as new content arrives. - [Small language model](https://agentik-os.com/glossary/small-language-model): A small language model is a language model with relatively few parameters, designed to run efficiently on limited hardware such as laptops or phones, often trading breadth for speed and cost. - [SOC 2](https://agentik-os.com/glossary/soc-2): SOC 2 is an auditing framework from the American Institute of CPAs that assesses how a service organization protects customer data, based on criteria covering security, availability, processing integrity, confidentiality and privacy. - [Soft prompt](https://agentik-os.com/glossary/soft-prompt): A soft prompt is a set of learned numeric vectors prepended to a model's input instead of human-readable words. Prompt tuning trains these vectors for a task while the model's own weights stay frozen. - [Softmax](https://agentik-os.com/glossary/softmax): Softmax is a function that converts a list of raw scores into probabilities that are all positive and sum to one. Language models use it to turn logits into a distribution over possible next tokens. - [Span](https://agentik-os.com/glossary/span): A span is a single timed operation within a trace, such as one model call or database query, carrying its start time, duration, metadata and a link to its parent operation. - [Sparse retrieval](https://agentik-os.com/glossary/sparse-retrieval): Sparse retrieval is finding documents using sparse vectors in which most values are zero and each dimension corresponds to a vocabulary term, as in BM25 or learned sparse models. - [Special tokens](https://agentik-os.com/glossary/special-tokens): Special tokens are reserved tokens that carry structural meaning rather than ordinary text, such as markers for the start of a message, a role change or the end of a sequence. - [Speculative decoding](https://agentik-os.com/glossary/speculative-decoding): Speculative decoding is an inference acceleration technique in which a small, fast draft model proposes several tokens that a larger model verifies in one step, producing the same outputs faster. - [Speech recognition](https://agentik-os.com/glossary/speech-recognition): Speech recognition is the use of AI models to convert spoken audio into written text. Modern systems use neural networks trained on large amounts of transcribed speech. - [SPLADE](https://agentik-os.com/glossary/splade): SPLADE is a learned sparse retrieval model that uses a language model to assign weights to vocabulary terms, including related terms absent from the text, combining keyword-index efficiency with semantic matching. - [State machine](https://agentik-os.com/glossary/state-machine): A state machine is a model of a system as a fixed set of states with defined transitions between them, used in orchestration to make an agent's or workflow's possible paths explicit and predictable. - [State space model](https://agentik-os.com/glossary/state-space-model): A state space model is a sequence modeling architecture that processes inputs through a compact, continuously updated hidden state, offering an alternative to attention that scales more efficiently with sequence length. - [Step-back prompting](https://agentik-os.com/glossary/step-back-prompting): Step-back prompting is a technique that asks a language model to first state the general principle or higher-level concept behind a question, then use that abstraction to reason toward the specific answer. - [Stochastic gradient descent](https://agentik-os.com/glossary/stochastic-gradient-descent): Stochastic gradient descent is a variant of gradient descent that updates parameters using small random subsets of the training data rather than the whole dataset, making training faster and more scalable. - [Stop condition](https://agentik-os.com/glossary/stop-condition): A stop condition is a rule that tells an agent loop when to end, such as the model producing a final answer, a goal check passing, an error occurring or an iteration or budget limit being reached. - [Stop sequence](https://agentik-os.com/glossary/stop-sequence): A stop sequence is a string that, when generated by a language model, causes generation to halt immediately, used to end output at a known boundary such as a closing tag. - [Streaming](https://agentik-os.com/glossary/streaming): Streaming is delivering a model's response incrementally, token by token or chunk by chunk, as it is generated, so users see output immediately instead of waiting for the full answer. - [Structured output](https://agentik-os.com/glossary/structured-output): Structured output is model output that follows a predefined, machine-readable format, such as JSON matching a schema, so software can parse and use it reliably without free-text interpretation. - [Subagent](https://agentik-os.com/glossary/subagent): A subagent is an agent started by another agent to handle a specific subtask in its own separate context, returning only its result so the parent agent's context stays focused. - [Summary memory](https://agentik-os.com/glossary/summary-memory): Summary memory is a memory strategy that replaces older parts of a conversation with a running summary, preserving key points while using far fewer tokens than the full history. - [Supervised fine-tuning](https://agentik-os.com/glossary/supervised-fine-tuning): Supervised fine-tuning is the stage of training in which a pretrained model learns from curated examples of inputs paired with ideal outputs, teaching it to follow instructions and respond in a desired format. - [Supervised learning](https://agentik-os.com/glossary/supervised-learning): Supervised learning is a machine learning approach in which a model learns from examples paired with correct answers, so it can predict the answer for new inputs. - [Supervisor agent](https://agentik-os.com/glossary/supervisor-agent): A supervisor agent is an agent that manages a group of other agents, deciding which one should act next, passing them tasks and context, and checking their outputs before continuing or finishing. - [Swarm intelligence](https://agentik-os.com/glossary/swarm-intelligence): Swarm intelligence is collective problem solving that emerges from many simple agents following local rules and interacting with each other, inspired by ant colonies, bird flocks and bee swarms. - [SWE-bench](https://agentik-os.com/glossary/swe-bench): SWE-bench is a benchmark that tests whether AI systems can resolve real issues from open-source GitHub repositories by producing code changes that make the project's tests pass. - [Sycophancy](https://agentik-os.com/glossary/sycophancy): Sycophancy is the tendency of an AI model to tell users what they want to hear, agreeing with their opinions or mistakes instead of giving accurate and honest answers. - [Synthetic data](https://agentik-os.com/glossary/synthetic-data): Synthetic data is artificially generated data, often produced by AI models, used to train or evaluate other models when real data is scarce, expensive, or sensitive. - [System prompt](https://agentik-os.com/glossary/system-prompt): A system prompt is a set of instructions given to a language model at the start of a conversation, separate from user messages, that defines its role, rules, tone and constraints for the whole session. - [System prompt leakage](https://agentik-os.com/glossary/system-prompt-leakage): System prompt leakage is the unintended disclosure of a model's hidden instructions or configuration to users, often through crafted questions, which can expose business logic, secrets or ways to bypass safeguards. - [Tail latency](https://agentik-os.com/glossary/tail-latency): Tail latency is the response time experienced by the slowest fraction of requests, often reported as the 95th or 99th percentile, revealing delays that averages hide. - [Task allocation](https://agentik-os.com/glossary/task-allocation): Task allocation is the process of deciding which agent or worker should handle each task in a multi-agent system, based on factors such as capabilities, availability, cost and workload. - [Task queue](https://agentik-os.com/glossary/task-queue): A task queue is a system that holds units of work waiting to be processed and distributes them to available workers, tracking which tasks are pending, running, completed or failed. - [Temperature](https://agentik-os.com/glossary/temperature): Temperature is a sampling setting that controls how random a language model's output is. Lower values make responses more focused and predictable, while higher values make them more varied. - [Tensor](https://agentik-os.com/glossary/tensor): A tensor is a multidimensional array of numbers that generalizes scalars, vectors, and matrices. Tensors are the core data structure used to store inputs, weights, and activations in deep learning. - [TensorRT-LLM](https://agentik-os.com/glossary/tensorrt-llm): TensorRT-LLM is an open-source NVIDIA library that optimizes and runs large language model inference on NVIDIA GPUs, using techniques such as kernel fusion, quantization and in-flight batching. - [Test set](https://agentik-os.com/glossary/test-set): A test set is a portion of data kept separate from training and tuning, used only to measure how well a model performs on examples it has not seen before. - [Test-time compute](https://agentik-os.com/glossary/test-time-compute): Test-time compute is the computation a model spends while answering, rather than during training. Letting a model reason longer or sample more candidate answers at this stage can improve accuracy. - [Text-to-image model](https://agentik-os.com/glossary/text-to-image-model): A text-to-image model is a generative AI model that creates images from written descriptions, usually using diffusion techniques guided by a text encoder. - [Text-to-speech](https://agentik-os.com/glossary/text-to-speech): Text-to-speech is the use of AI models to convert written text into natural-sounding spoken audio, often with controllable voice, style, and language. - [Text-to-SQL](https://agentik-os.com/glossary/text-to-sql): Text-to-SQL is using a language model to translate a natural language question into a SQL query that is run against a database, letting users retrieve structured data without writing SQL. - [Text-to-video model](https://agentik-os.com/glossary/text-to-video-model): A text-to-video model is a generative AI model that produces short video clips from written descriptions, extending image generation techniques to keep motion consistent across frames. - [TF-IDF](https://agentik-os.com/glossary/tf-idf): TF-IDF is a weighting scheme that scores a word's importance to a document by how often it appears there, discounted by how common the word is across the whole collection. - [Throughput](https://agentik-os.com/glossary/throughput): Throughput is the total amount of work an AI system completes in a given time, such as requests or tokens processed per second across all users, reflecting capacity rather than single-request speed. - [Time to first token](https://agentik-os.com/glossary/time-to-first-token): Time to first token is the delay between sending a prompt to a language model and receiving the first piece of its response, which largely determines how fast a streaming answer feels. - [Timeout](https://agentik-os.com/glossary/timeout): A timeout is a maximum amount of time a step, tool call or request is allowed to take before it is abandoned and treated as failed, preventing stuck work from blocking a workflow. - [Token](https://agentik-os.com/glossary/token): A token is the basic unit of text a language model reads and writes, often a word, part of a word, or punctuation mark. Model limits and usage costs are usually measured in tokens. - [Token budget](https://agentik-os.com/glossary/token-budget): A token budget is the number of tokens allotted to a request or task, covering prompt, retrieved context and response, used to manage cost, latency and the limits of the context window. - [Token cost](https://agentik-os.com/glossary/token-cost): Token cost is the price charged for using a language model, usually billed per million input and output tokens, with output tokens generally priced higher than input tokens. - [Tokenization](https://agentik-os.com/glossary/tokenization): Tokenization is the process of splitting text into tokens and mapping each one to a numerical ID from a fixed vocabulary, so a language model can process it. - [Tokens per second](https://agentik-os.com/glossary/tokens-per-second): Tokens per second is a measure of how quickly a language model generates output once it starts responding, used to compare the speed of models, hardware and serving setups. - [Tool calling](https://agentik-os.com/glossary/tool-calling): Tool calling is the ability of a language model to request that an external function, API or program be run by outputting a structured call with arguments, then use the returned result in its next response. - [Tool chaining](https://agentik-os.com/glossary/tool-chaining): Tool chaining is the practice of an agent using the output of one tool call as the input to the next, combining several tools in sequence to complete a task no single tool can handle. - [Tool choice](https://agentik-os.com/glossary/tool-choice): Tool choice is a model API setting that controls whether the model may decide to call tools, must call some tool, must call one specific tool, or is not allowed to call tools at all. - [Tool description](https://agentik-os.com/glossary/tool-description): A tool description is the natural language text attached to a tool that tells a model what the tool does and when to use it, and its clarity strongly affects whether the model picks the right tool. - [Tool permissions](https://agentik-os.com/glossary/tool-permissions): Tool permissions are the rules that define which tools an agent may use, with which arguments and on which resources, and which actions need explicit approval from a person before they run. - [Tool registry](https://agentik-os.com/glossary/tool-registry): A tool registry is a catalog that stores the definitions of tools available to agents, so they can be discovered, versioned, access controlled and loaded into an agent's context when needed. - [Tool schema](https://agentik-os.com/glossary/tool-schema): A tool schema is the machine-readable definition of a tool given to a model, listing its name, purpose and the names, types and constraints of its input parameters so the model can call it correctly. - [Tool selection](https://agentik-os.com/glossary/tool-selection): Tool selection is the decision an agent makes about which of its available tools to use for the current step, based on the task, the tool descriptions and the results it has seen so far. - [Top-k retrieval](https://agentik-os.com/glossary/top-k-retrieval): Top-k retrieval is returning the k highest-scoring results for a query, where k is a chosen number that trades off between including enough relevant context and adding noise. - [Top-k sampling](https://agentik-os.com/glossary/top-k-sampling): Top-k sampling is a text generation method that restricts the choice of each next token to the k most probable candidates, then samples among them. - [Top-p sampling](https://agentik-os.com/glossary/top-p-sampling): Top-p sampling is a text generation method that picks the next token only from the smallest set of candidates whose combined probability reaches a threshold p, trimming unlikely options. - [Toxicity](https://agentik-os.com/glossary/toxicity): Toxicity is language that is rude, hateful, harassing or otherwise harmful, and toxicity scores from classifiers are commonly used to evaluate and filter the outputs of AI models. - [TPU](https://agentik-os.com/glossary/tpu): A TPU is a custom AI accelerator chip designed by Google to speed up the matrix operations used in machine learning, available mainly through Google Cloud. - [Tracing](https://agentik-os.com/glossary/tracing): Tracing is recording the path of a single request as it moves through the components of a system, such as model calls, retrievals and tool invocations, with timing for each step. - [Training](https://agentik-os.com/glossary/training): Training is the process of adjusting a model's parameters using data so that its outputs become more accurate. It typically requires far more computation than using the finished model. - [Training data](https://agentik-os.com/glossary/training-data): Training data is the collection of examples a machine learning model learns from. Its quality, size, and diversity strongly influence what the model can do and which biases it inherits. - [Transfer learning](https://agentik-os.com/glossary/transfer-learning): Transfer learning is the practice of reusing a model trained on one task or dataset as the starting point for a different but related task, reducing the data and computation needed. - [Transformer](https://agentik-os.com/glossary/transformer): A transformer is a neural network architecture that processes sequences using attention to relate every element to every other element. Introduced in 2017, it is the basis of most modern language models. - [Transparency](https://agentik-os.com/glossary/transparency): Transparency in AI is openness about how a system works, what data it uses, its limitations and when people are interacting with AI, enabling users and regulators to make informed judgments. - [Tree of thoughts](https://agentik-os.com/glossary/tree-of-thoughts): Tree of thoughts is a prompting framework in which a language model explores several branching lines of reasoning, evaluates partial solutions and can backtrack, rather than following a single linear chain of thought. - [Trigger](https://agentik-os.com/glossary/trigger): A trigger is an event or condition that automatically starts a workflow or agent run, such as a new email, a form submission, a file upload, a schedule or an incoming webhook. - [Triple](https://agentik-os.com/glossary/triple): A triple is the basic unit of a knowledge graph, stating a single fact as subject, predicate and object, for example a company, the relation "headquartered in" and a city. - [Underfitting](https://agentik-os.com/glossary/underfitting): Underfitting happens when a model is too simple or insufficiently trained to capture the patterns in the data, so it performs poorly on both training data and new examples. - [Unsupervised learning](https://agentik-os.com/glossary/unsupervised-learning): Unsupervised learning is a machine learning approach in which a model finds structure in data without labeled answers, for example by grouping similar items or compressing information. - [User prompt](https://agentik-os.com/glossary/user-prompt): A user prompt is the message a person or application sends to a language model within a conversation, usually containing the actual request or question, as distinct from the system prompt that sets overall behavior. - [Utility-based agent](https://agentik-os.com/glossary/utility-based-agent): A utility-based agent is an agent that chooses among possible actions by estimating how desirable each resulting outcome would be, using a utility function to weigh tradeoffs rather than only checking whether a goal is met. - [Validation set](https://agentik-os.com/glossary/validation-set): A validation set is a portion of data held out from training and used to tune hyperparameters and detect overfitting while a model is being developed. - [Vanishing gradient problem](https://agentik-os.com/glossary/vanishing-gradient-problem): The vanishing gradient problem occurs when gradients become extremely small as they are propagated back through many layers, causing early layers of a deep network to learn very slowly or not at all. - [Variational autoencoder](https://agentik-os.com/glossary/variational-autoencoder): A variational autoencoder is a generative autoencoder that learns a smooth probability distribution over its latent space, so new data can be generated by sampling points from that space. - [Vector](https://agentik-os.com/glossary/vector): A vector is an ordered list of numbers. In AI, vectors represent data such as words, images, or model states so they can be compared and processed mathematically. - [Vector database](https://agentik-os.com/glossary/vector-database): A vector database is a database designed to store embedding vectors along with their metadata and quickly find the vectors most similar to a query vector, often using approximate nearest neighbor indexes. - [Vector index](https://agentik-os.com/glossary/vector-index): A vector index is a data structure that organizes embedding vectors so a system can quickly find the ones most similar to a query, usually trading a little accuracy for large speed gains. - [Vector search](https://agentik-os.com/glossary/vector-search): Vector search is finding items whose embedding vectors are closest to a query vector under a similarity measure, which lets a system match content by meaning rather than exact words. - [Virtual private cloud](https://agentik-os.com/glossary/virtual-private-cloud): A virtual private cloud is a logically isolated section of a public cloud where an organization runs resources on its own private network, controlling IP addresses, routing and access. - [Vision-language model](https://agentik-os.com/glossary/vision-language-model): A vision-language model is a multimodal model that takes both images and text as input, enabling tasks such as describing pictures, answering questions about images, and reading documents. - [vLLM](https://agentik-os.com/glossary/vllm): vLLM is an open-source library for fast, memory-efficient serving of large language models, known for PagedAttention and continuous batching, and it can expose an OpenAI-compatible API. - [Vocabulary](https://agentik-os.com/glossary/vocabulary): A vocabulary is the fixed set of tokens a tokenizer and language model can recognize and produce, each mapped to a unique numeric ID. - [Voice agent](https://agentik-os.com/glossary/voice-agent): A voice agent is an AI agent that interacts through spoken conversation, combining speech recognition, a language model and speech synthesis, or a speech-native model, to talk with people and take actions. - [VRAM](https://agentik-os.com/glossary/vram): VRAM is the dedicated memory on a GPU that holds model weights, activations and caches during computation, and its size largely determines which models a given GPU can run. - [Web search tool](https://agentik-os.com/glossary/web-search-tool): A web search tool is a tool that lets a model send queries to a search engine and receive results or page content, so it can answer with information that is newer than its training data. - [Webhook](https://agentik-os.com/glossary/webhook): A webhook is an HTTP request that one application sends automatically to a specified URL when an event occurs, commonly used to notify another system and trigger a workflow in real time. - [WebSocket](https://agentik-os.com/glossary/websocket): WebSocket is a communication protocol that keeps a persistent, two-way connection open between a client and a server, used for real-time applications such as voice agents and live collaborative interfaces. - [Weights](https://agentik-os.com/glossary/weights): Weights are the learned numerical values that determine how strongly each input influences a neuron's output. Training adjusts the weights so the model's predictions better match the data. - [WordPiece](https://agentik-os.com/glossary/wordpiece): WordPiece is a subword tokenization algorithm, used by BERT and related models, that builds a vocabulary by adding the word pieces that most improve the likelihood of the training text. - [Worker pool](https://agentik-os.com/glossary/worker-pool): A worker pool is a fixed or scalable set of processes, threads or agents that pull tasks from a shared queue and execute them, allowing many tasks to run in parallel with bounded resources. - [Workflow automation](https://agentik-os.com/glossary/workflow-automation): Workflow automation is the use of software to run a sequence of business tasks, such as moving data, sending messages and updating records, according to defined rules with little manual effort. - [Workflow engine](https://agentik-os.com/glossary/workflow-engine): A workflow engine is software that runs defined sequences of steps, tracking their state, handling branching, retries and failures, and ensuring each step runs in the right order. - [Working memory](https://agentik-os.com/glossary/working-memory): Working memory in AI agents is the information actively held and manipulated during the current step of a task, such as goals, intermediate results and scratch notes, typically kept in the context. - [World model](https://agentik-os.com/glossary/world-model): A world model is an AI model that learns an internal representation of how an environment behaves, so it can predict the consequences of actions or simulate future states. - [Zero-shot chain-of-thought](https://agentik-os.com/glossary/zero-shot-chain-of-thought): Zero-shot chain-of-thought is a prompting technique that elicits step-by-step reasoning without examples, typically by adding a short cue such as "Let's think step by step" to the prompt. - [Zero-shot prompting](https://agentik-os.com/glossary/zero-shot-prompting): Zero-shot prompting is asking a language model to perform a task using only instructions, without providing any worked examples, relying on what the model already learned during training. ## Essays - [Build vs buy an AI agent system: an honest decision framework](https://agentik-os.com/blog/build-vs-buy-an-ai-agent-system-an-honest-decision-framework): Build vs buy for AI agents is not a choice about models. It is a choice about who owns auth, memory, evals, retries, and the pager at 2am. This piece prices both sides with the assumptions on the page, names the cases where each one wins, and gives you the test that settles it. - [Chatbot, copilot, agent, operating system: a buyer's map](https://agentik-os.com/blog/chatbot-copilot-agent-operating-system-a-buyer-s-map): Chatbot, copilot, agent and operating system are four different purchases, not four words for the same thing. This map places each one on six things you can check before you sign: what you install, who runs the model, what it remembers, what it may do on its own, what it costs to run, and the way it breaks. Use it on the product in the tab next to this one. - [Choosing your AI host: the five questions that matter](https://agentik-os.com/blog/choosing-your-ai-host-the-five-questions-that-matter): Five questions decide whether a host can run the tools you plan to install: remote MCP with OAuth, which machine opens the call to your server, what is still there after a restart, whether a non-coder can finish the setup, and the seat bill at your head count. Each one has a test you can run in ten minutes. Where a vendor does not write the answer down, this page says we do not know. - [Cost control for agent systems: where the tokens actually go](https://agentik-os.com/blog/cost-control-for-agent-systems-where-the-tokens-actually-go): An agent bill is six line items, not one: the system prompt, the tool schemas, the tool results, the retries, the fan-out to other agents, and the history you resend on every turn. Five of the six can be measured today with a token counter and the usage object you already get back. This page shows how to measure each one and which fixes pay, in order. - [Fine-tuning or context: which problem are you solving](https://agentik-os.com/blog/fine-tuning-or-context-which-problem-are-you-solving): Fine-tuning changes how a model behaves. Retrieval changes what it knows at the moment you ask. If you are picking between them for a support, research or internal-docs assistant, start from the broken output: this piece names the five ways an answer goes wrong, maps each one to the fix that matches it, and gives you three cheap tests that tell them apart in an afternoon. - [How to add an MCP server to Cursor](https://agentik-os.com/blog/how-to-add-an-mcp-server-to-cursor): Cursor reads MCP servers from a file called mcp.json, in your home folder or in the project. This piece gives you the exact JSON for both kinds of server, the three places you check that it is live, and a table that maps every failure you will hit to its cause. - [Measuring return on an AI system without fooling yourself](https://agentik-os.com/blog/measuring-return-on-an-ai-system-without-fooling-yourself): Most AI ROI numbers are built on people guessing how long a task would have taken. That guess is made after the result is known, which is where the error lives. Here is how to set a baseline before the tool lands, what to log per task, why output counts and outcome counts split apart, and how to run a fair before and after when volume moves under you. - [What to ask an AI vendor before you sign](https://agentik-os.com/blog/what-to-ask-an-ai-vendor-before-you-sign): Eight questions decide whether an AI deal is safe to sign: who pays for inference, where your data goes, what you keep on exit, what the model is, what the system does alone, what the log holds, what broke last year, and how the deal ends. This is what a good answer sounds like, what a dodge sounds like, and the follow-up that ends it. - [What is an AI operating system?](https://agentik-os.com/blog/what-is-an-ai-operating-system): An AI operating system is a set of specialized agents, shared memory, and skills that runs inside the host you already pay. Agentik never buys your tokens. - [AI operating system template for Claude: build, or install](https://agentik-os.com/blog/ai-operating-system-template-for-claude): An AI operating system template for Claude is a repository you assemble. An installed OS is the same idea, already named, already constrained, delivered to the host you pay. - [One agentic OS, four hosts: Claude, Cursor, ChatGPT, Codex](https://agentik-os.com/blog/agentic-os-four-hosts): An agentic OS for Claude Code is not a different product from the one Cursor or ChatGPT runs. It is the same operative system, reached through MCP, on the host you already pay. - [Content OS: an AI content agent that stays in the host](https://agentik-os.com/blog/content-os-ai-content-agent): An AI content agent is one job. Content OS is the line: brief, draft, SEO pass, and the cut that follows, on the host you already pay. - [Claude Code for content marketing, without a fake weekly quota](https://agentik-os.com/blog/claude-code-for-content-marketing): Claude Code for content marketing is a host plus a line of work. The line is brief, draft, constraint check, and the next cut. The number of pieces is yours to count, not ours to invent. - [Growth OS: AI agents for marketing teams, no new tool](https://agentik-os.com/blog/growth-os-marketing-teams): AI agents for marketing teams are useful when they share one operating system. Growth OS is that system: it looks for the gap, on the host you already pay. - [MCP servers for marketing and SEO: what to judge before you add one](https://agentik-os.com/blog/best-mcp-servers-for-marketing): The best MCP server for a marketing team is the one whose auth, write scope, and token bill you can say out loud. A list that cannot say those three things is an advertisement. - [How to add Agentik’s remote MCP server](https://agentik-os.com/blog/add-a-remote-mcp-server): You add a remote MCP server by pointing the host at https://mcp.agentik-os.com/api/mcp. agentik-os.com is the site. It is not the endpoint. - [Fractional chief AI officer: what the role is, and what Agentik sells](https://agentik-os.com/blog/fractional-chief-ai-officer): A fractional chief AI officer is a senior AI lead you do not hire full time. Agentik’s on-demand work is narrower and plainer: we price the gap we can prove, then install an operative system. We do not publish a CAIO retainer. - [An AI implementation plan for a small company, in 30, 60, and 90 days](https://agentik-os.com/blog/ai-implementation-plan-30-60-90): AI implementation for my business starts with the host you already pay, one official OS, and a written gap. It does not start with a platform evaluation. - [AI readiness checklist: twelve questions before you spend](https://agentik-os.com/blog/ai-readiness-checklist): An AI readiness checklist is a list of questions you can answer without a vendor in the room. If you need someone to interpret the answers, that is an audit, not a checkbox. - [AI governance for agents is a human gate](https://agentik-os.com/blog/ai-governance-and-the-human-gate): AI governance on Agentik is a human gate: nothing leaves until a person approves it. An AI strategy that skips that gate is a chatbot with permissions. This page is not legal advice. - [Teaching an OS your company facts without training a model](https://agentik-os.com/blog/teaching-an-os-your-company-facts-without-training-a-model): For company facts, teach the operating layer before you train the model. You want external memory, retrieval, access control, and approval gates so an agent can find current policy, cite its source, and forget stale rules without a model job. - [AI for agencies: one OS per client without mixing data](https://agentik-os.com/blog/ai-for-agencies-one-os-per-client-without-mixing-data): Marketing agencies can use one AI OS per client to keep roles, memory, files, approvals, and brand rules from blurring together. That pattern reduces operator mistakes, but it is not security isolation by itself. This article shows the boundary you need below the OS: credentials, retrieval, MCP authorization, human approval, and audit trails. - [The return is the hour you can point to](https://agentik-os.com/blog/return-without-invented-numbers): A return that cannot be traced to a clock, a rejected draft, or a number the company already keeps is not a return. It is a slide. This essay is the method, not a promise. - [Orchestration is the operating system, not a bigger chat](https://agentik-os.com/blog/orchestration-is-the-operating-system): A pile of agents is still a pile. An operating system is the agreement about who drafts, who remembers, who is allowed to act, and who must approve. That agreement is the product. - [Context gaps show up before the agents do](https://agentik-os.com/blog/context-gaps-before-agents): An agent that cannot see the brief, the brand, the approval, or the last decision will improvise. That improvisation is the gap. Closing it is the work, before anyone asks the model to be autonomous. ## External references - [Model Context Protocol specification](https://modelcontextprotocol.io/specification): the open standard Agentik speaks. - [Anthropic MCP documentation](https://docs.anthropic.com/en/docs/mcp): how a Claude host adds a remote MCP server. - [OpenAI MCP documentation](https://platform.openai.com/docs/mcp): the same protocol from ChatGPT and Codex. - [Cursor MCP documentation](https://docs.cursor.com/context/model-context-protocol): Cursor's configuration reference. ## Full text - [llms-full.txt](https://agentik-os.com/llms-full.txt) # Build vs buy an AI agent system: an honest decision framework URL: https://agentik-os.com/blog/build-vs-buy-an-ai-agent-system-an-honest-decision-framework Published: 2026-09-19; updated: 2026-09-19 Build vs buy for AI agents is not a choice about models. It is a choice about who owns auth, memory, evals, retries, and the pager at 2am. This piece prices both sides with the assumptions on the page, names the cases where each one wins, and gives you the test that settles it. ## What build vs buy actually means for AI agents You are not choosing whether to build a model. You will rent that either way. The real split is the layer above it: the code that picks an agent, feeds it the right context, calls a tool, checks the result, retries the bad ones, and logs what it did. Call it the runtime. The runtime is what you build or buy. That layer is small on day one. A loop, a prompt, two tools. It grows when real use hits it. A user asks the same thing twice and gets two answers. A tool call times out and the agent says it worked. Someone leaves and no one can say why the agent was told to skip step three. None of that is a model problem. All of it lives in the runtime. So write the question down in the form that can be priced: who owns the runtime, who owns the data path, and who is on call when it breaks at 2am on a Sunday. A demo answers none of those. A year of use answers all three. - The model: rented in both cases. Not a build vs buy question. - The runtime: the loop, the tools, the state, the gate. This is the choice. - The data path: what the agent may read, and where the text lands. - The pager: who wakes up, and who can fix it while awake. ## Why the demo takes a week and the system takes two quarters A working demo is cheap now. One good engineer can wire an agent to a tool, put a chat box on it, and show it doing real work in a week. The demo is honest about one thing: the model can do the task. It is silent about the other ten things the task needs to be a system. The gap shows up in an order you can predict from the mechanism, not from a survey. First the agent gets the wrong data, so you add search. Then it gets the right data but says it in the wrong shape, so you add a schema. Then it works for one user and breaks for the next, so you add per-user state. Then it does the same job twice and sends two emails, so you add keys and a gate. Then someone changes a prompt and three things get worse, so you add evals. By that point you have written a small platform and no one on the team calls it that. That is the cost people miss. Not the first week. The next forty, spent on plumbing that has nothing to do with your product. If you are going to pay it, pay it on purpose, for a reason you can say in one sentence. ## The parts of building that never make it into the estimate Ask a team what it costs to build an agent system and you get the model call and the UI. Here is the rest of the list. Each line is real work, each one has a known shape, and each one is skipped in the first plan. Read this list as a budget, not as a warning. Every item is doable. Four of them are the reason the second quarter looks nothing like the first. - Auth. Not your app login. The agent needs a token for each tool it touches, scoped per user, with a refresh path. Human accounts and agent accounts age at different rates, and the refresh is the part that breaks on a holiday. - Memory. What the agent knows across turns, across days, and across people. A chat log is not memory. You need a write path, a read path, a size cap, and a rule for what to drop first. - Evals. A test set of real cases, a way to score them, and a habit of running them before a prompt ships. Without it, every prompt edit is a guess and you learn the result from a user. - Retries and keys. Models time out. Tools return half a result. You need to know which calls are safe to repeat, and hold a key so the same job cannot send the same invoice twice. - Observability. One trace per run: the prompt, the tool calls, the tokens, the cost, the end state. If you cannot open one bad run and read it top to bottom, you cannot fix anything. - The gate. The step where a human says yes before the agent sends, posts, pays, or deletes. Cheap to add early, painful to retrofit once a dozen call sites exist. - The second engineer. One person can hold a runtime in their head. Then they go on leave, or leave. The system is only as alive as the number of people who can change it safely, and that number needs to be at least two. ## A worked cost comparison, with the assumptions written down Below is a first-year cost model for one line of work, such as a content line or a support line, used by ten people. The unit is engineer-weeks, not money, because your loaded cost per engineer is a number you know and I do not. Multiply the column by your own rate and add the token bill, which you pay on your own account in both cases. The numbers are assumptions. They are not a study, a survey, or a benchmark. I have written each one as a claim you can argue with, and the model is only useful if you replace them with your own. If your team has already built auth for tools, cut that row to zero. If you have no eval habit at all, the build column is worse than what I wrote, not better. Read the total as a range, not a figure. With the assumptions above, the build column comes to about four times the buy column, and the gap is not the agent logic. It is auth, evals, and the trace. Change an assumption and the ratio changes with it, which is the point of writing them down. - Assumption 1: one line of work, ten users, four tools, one host. Not a whole company. - Assumption 2: your engineers are good and have not built an agent runtime before. - Assumption 3: you pay the model tokens yourself in both columns. That bill does not change with the decision. - Assumption 4: buying still costs you real weeks. Nobody installs a system and walks away. - Assumption 5: first year only. Year two is mostly upkeep on the build side and mostly price on the buy side. ## What buying an AI agent platform actually costs you Buying is not free and the price is not the invoice. Three costs matter and none of them show up on a pricing page. Lock-in is the first. The question to ask is not whether you are locked in. You are, a bit, in every case. The question is the size of the exit: if this vendor doubled its price or shut down next month, how many weeks to be running again. If the answer is a week, the lock-in is cheap. If the answer is a quarter and nobody can name the steps, you are buying a dependency, not a tool. Fit is the second. A bought system encodes someone else's idea of how the work goes. That is most of its value, and it is the thing that will grate. If your work is normal, a stranger's shape fits fine and saves you months. If your work is the whole reason your company wins, a stranger's shape will cost you the edge and no amount of config will put it back. The data boundary is the third, and it is the one that gets a deal killed in review. Where does the text go. Who can read it. Is it used to train anything. Can you point at a document that says so. A vendor who answers that in one page is telling you they have been asked before. A vendor who sends a sales call instead has told you something too. - Exit cost: weeks to be running on something else. Ask for the steps, not a promise. - Fit cost: the work you will reshape to match the tool. Real, and worth it when the work is generic. - Data cost: where the text sits, who reads it, what it trains. Get it in writing before the pilot, not after. - Upgrade cost: a vendor change you did not ask for can break a prompt you depend on. Ask how they version it. ## When building your own AI agent system is the right call Build when the runtime is the product. If what you sell is agents doing a job for a customer, the loop is your margin and your moat, and handing it to a vendor means renting the thing you are supposed to own. Same answer if the agent touches a system so odd that no vendor has ever seen its shape. Build when the constraint is hard and legal. Some data cannot leave a boundary, and the sentence saying so came from a regulator, not from a preference. In that case the build cost is not a choice, it is the price of being allowed to operate, and the comparison table above is the wrong tool. Build when you already have the platform. If you run a tool bus, an eval harness, a trace pipeline and an on-call rota, most of the rows in the cost table are already paid. The marginal cost of one more agent line is small, and buying would mean a second control plane beside the one that works. One warning on all three. Teams pick build for a fourth reason they do not say out loud: building is more fun than buying, and the first week of an agent build is the most fun week of the year. That is not a reason. Write the reason down, show it to someone who will not be writing the code, and see if it survives. - The runtime is what you sell. - A rule you did not write forbids the data leaving. - You already own the platform pieces and the rota. - You have a second engineer who can hold it. Not a plan to hire one. ## When buying is the right call, and how to buy well Buy when the work is real but generic. Drafting, research, record keeping, the weekly report, the first pass at a spec. These jobs look the same in most companies, and the parts you would build, memory and evals and the gate, would end up looking like everyone else's. Paying for the shape is the cheap move. Buy when the team is small. Below a certain size, one engineer on a runtime is your entire engineering capacity for a quarter. That is not a build decision, it is a decision to stop shipping your product for three months. Buy when the thing you actually need is speed of learning. A bought system tells you within two weeks whether an agent helps this line of work at all. That answer is worth more than a better runtime, because the answer is often no, and finding out for two weeks of effort instead of two quarters is the whole point. Buying well means buying with an exit. Keep your prompts and your eval set in your own repo. Keep the token account in your name. Ask, before you sign, what you walk out with: the text, the config, the history, in a format you can read without their app. If a vendor cannot answer that, the price on the page is not the price. ## The middle path: buy the runtime, own the judgment Most good answers are not a clean side. The split that holds up is this one: buy the parts that are the same in every company, own the parts that are only true in yours. The parts that are the same: the protocol to reach tools, the auth dance, the trace format, the retry rules, the approval step, the roster of agents for a normal line of work. None of that is your edge. Writing it again teaches you nothing a vendor's docs would not have. The parts that are only yours: the constraint the work must respect, the tone, the list of things the agent may never do, the eval cases that come from your own bad days, and the record of what happened. Keep those in your repo, in plain files, under review like code. Then a vendor change is a bad afternoon and not a rebuild. There is a cost to the middle path, and it is coordination. Two owners means two release cycles and a seam between them, and seams are where bugs live. You pay that in exchange for a cheap exit. In my experience it is the right trade for anything that is not the core of the business, and the wrong one for anything that is. - Own: the constraint, the tone, the never-do list, the eval set, the record. - Buy: the protocol, the auth, the trace, the retries, the gate, the roster. - Keep the token account in your name, whichever side you land on. - Keep prompts in files, in git, with a diff. Not in a vendor text box. ## The exit test: the only number that settles the argument When a build vs buy debate stalls, it is usually because both sides are pricing the entry. Price the exit instead. Pick the vendor you are considering, then answer this in writing: if they were gone on Monday, what would we do, in order, and how long would it take. Run the same test against your own build, with the lead engineer gone instead of the vendor. The build side often has the worse answer, for a structural reason: the vendor at least wrote docs, while the runtime knowledge sits in one head and not in a repo. If the system you are buying speaks the Model Context Protocol, the mechanical part of the exit is small, because the config is a few lines you own. A server entry reads like the block below, and the spec is public. Three lines of config. Swapping that url is the mechanical part of an exit, and it is the easy part. The hard part is everything that lived in the vendor and not in your repo: the prompts, the eval cases, the memory, the audit trail. Whatever you cannot paste into a new config is the real lock-in, and it is worth measuring in weeks before you sign anything. - mcpServers: - your-os: - url: https://mcp.example.com/api/mcp - Exit test, written answer required: who does what, in what order, in how many weeks. - Run the same test on your own build with the author of the runtime removed. ## Failure modes on both sides, and what causes them Both paths fail in ways you can see coming. These are the ones that recur, with the cause rather than the symptom, because the symptom always looks like the model being bad. The pattern under most of them is the same: someone treated an agent as a feature when it was a system, or as a system when it was a feature. Match the weight of the decision to the weight of the thing. - Build: the agent works for the author and no one else. Cause: prompt tuned against one person's data, never run on a shared test set. - Build: cost triples in month three with no change in use. Cause: no per-run token trace, so nobody saw the retry loop. - Build: the system freezes after the author leaves. Cause: one owner, no docs, prompts in a database instead of files. - Build: an agent sends the same message twice. Cause: retries without keys, and no approval step on anything that leaves the building. - Buy: the pilot goes well and adoption dies at week six. Cause: bought for a problem nobody in the room actually had, measured by demo instead of by work done. - Buy: the tool is fine and the answers are wrong. Cause: the data boundary was never set up, so the agent is reasoning about a stale copy. - Buy: a vendor update breaks a workflow on a Tuesday. Cause: no pinned version, no eval set of your own to catch it. - Both: nobody can say if it helped. Cause: no baseline measured before the pilot started. ## Where Agentik sits in this decision Since this is our blog, the honest disclosure. Agentik {OS} is a buy-side option with a specific shape: official operating systems installed on the MCP host you already pay for, which today means Claude, Claude Code, Cursor, ChatGPT, Codex, or Hermes. The host runs the model and pays the tokens. We never buy your tokens, which means the cost line that scales with use stays on your own account and your own bill. In the terms of this article, that puts us on the middle path. You buy the roster and the protocol: Growth OS compiles 48 agents, Librarian 22, Builder 21, Content 9. Work that publishes, sends, spends, or resets waits for a human approval. One MCP tool, talk, answers a turn and returns a compact pack, about 2 KB on Growth OS against about 110 KB for the full roster, which is how the host stays cheap to run. Pricing is $19.99 lifetime for one OS, or $19 a month for three, $99 for ten, $199 for unlimited. Where we are not the answer: if the runtime is your product, buy nothing, including from us. If the data cannot leave your boundary, a hosted endpoint is the wrong shape. If your work is strange in the way that makes you money, a published roster will fit badly, and we would rather you knew that before the invoice than after. The install path is in the Docs, and /docs/mcp has the per-host config. ## What this framework does not settle The cost table is a model, and every model is wrong in the same way: it prices the work you can name. The line it cannot price is organisational. A bought system that the team quietly refuses to use costs more than a build that three people love, and no table will tell you which one you have. The only way to find out is to put the thing in front of the people who will use it and watch what they do in week six, not week one. This framework also assumes the ground stays still for a year, and it does not. Model prices move, context windows move, and a capability that needed a custom build in one quarter arrives as a feature in the next. That cuts toward buying small and reversibly rather than building for a future spec. It is a bias, and I am stating it as one rather than pretending it fell out of the analysis. Last limit, and it is the flat one: I cannot tell you what a vendor will do, and neither can the vendor. Contracts, exit clauses and data terms are how you handle that, and they are not an engineering decision. Bring the person who reads contracts into the room before the pilot, not after the pilot went well. ## First-year effort for one line of work, in engineer-weeks. Assumptions are stated in the section above and are not measured market data. | Line item | Build | Buy | Note | | --- | --- | --- | --- | | Agent logic and prompts | 3 | 2 | The part everyone estimates | | Tool auth, per user, with refresh | 4 | 0.5 | OAuth flow on the build side | | Memory: write path, read path, size cap | 4 | 1 | Chat history is not memory | | Retries, timeouts, idempotency keys | 3 | 0 | Bought runtimes ship this | | Eval set and the habit of running it | 4 | 2 | You own the cases either way | | Tracing, cost per run, one readable log | 3 | 0.5 | Needed to debug anything | | Human approval gate | 2 | 0 | Cheap early, painful later | | Host and tool integration | 2 | 1 | Config on the buy side | | Upkeep and on-call, first year | 6 | 1 | Does not stop | | Second engineer onboarding | 2 | 0.5 | The bus factor line | | Total, engineer-weeks | 33 | 8.5 | Multiply by your loaded rate | | Token bill | Yours | Yours | Unchanged by the decision | ## Sources - [Model Context Protocol specification](https://modelcontextprotocol.io/specification/2025-06-18) - [Anthropic, Building effective agents](https://www.anthropic.com/engineering/building-effective-agents) - [OpenTelemetry semantic conventions for generative AI](https://opentelemetry.io/docs/specs/semconv/gen-ai/) - [OAuth 2.1 draft, IETF](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1) ## FAQ ### Is it cheaper to build or buy an AI agent system? On a first-year model of one line of work, buying costs a few engineer-weeks and building costs tens, because auth, memory, evals and tracing are the bulk of the work. Building wins later only if you run many lines on one platform you already own. ### What do people forget when they estimate building AI agents? Tool auth with refresh, real memory, an eval set, retries with idempotency keys, per-run tracing, the human approval step, and a second engineer who can change the system safely. Those lines are most of the year, and none of them are agent logic. ### How do I judge vendor lock-in for an agent platform? Run the exit test: write down, in order, what your team would do if the vendor disappeared on Monday, and how many weeks it would take. Anything that lives only in the vendor, such as prompts, eval cases and history, is the real lock-in. ### Should a small team build its own agent runtime? Usually not, because one engineer on a runtime is a whole quarter of a small team's capacity. Build only when the runtime is the product, when a rule forbids the data leaving, or when you already run the platform pieces. ### Can we buy now and build later? Yes, and that is the cheapest way to learn whether agents help this line of work at all. Keep your prompts, eval cases and token account in your own hands from day one so the later build starts with the parts that matter. ### Does buying an agent system mean the vendor pays for the model? Sometimes, and you should check, because it changes the shape of the bill and the data path. Agentik does not: the host you already pay runs the model and the tokens stay on your account. # Chatbot, copilot, agent, operating system: a buyer's map URL: https://agentik-os.com/blog/chatbot-copilot-agent-operating-system-a-buyer-s-map Published: 2026-09-19; updated: 2026-09-19 Chatbot, copilot, agent and operating system are four different purchases, not four words for the same thing. This map places each one on six things you can check before you sign: what you install, who runs the model, what it remembers, what it may do on its own, what it costs to run, and the way it breaks. Use it on the product in the tab next to this one. ## Copilot vs agent vs chatbot: what the words actually name The four words do not sit on a ladder from small to big. They name four different deals with four different bills and four different ways of going wrong. A vendor may use any of them for any product, so the word on the page is a weak signal and you should treat it as one. Here is the short form. A chatbot is a box you type into and it types back. A copilot lives inside a tool you already use and it makes the next move in that tool cheap. An agent takes a goal, runs a loop of its own, and stops when it thinks it is done. An operating system is a set of named jobs, a shared memory, and a rule about what has to stay true, on top of a model that someone else runs. None of that is a ranking. A chatbot is the right buy for a lot of work. The point of the map is that you can tell which one you are being sold in about twenty minutes, and then you can ask the right questions instead of the general ones. The six checks below are the map. They are dull on purpose. Each one has an answer that a vendor can give you in a sentence, and a way for you to see the answer for yourself if they will not. - What you install: a tab, a plugin, a service, or a config on a host you already have. - Who runs the model: them, you, or your host. - What it remembers: nothing, the thread, or a store you can read. - What it may do alone: draft, act on a short list, or act on anything. - What it costs to run: a seat, your tokens, or both. - How it fails: the wrong answer, the wrong move, or the wrong move at scale. ## Chatbot: a box that answers What you install is a tab, or a widget on your own site. There is no state on your side and often no admin to speak of. This is the whole appeal: you can have one by lunch. Who runs the model is the vendor, almost always. That matters more than it sounds. If they run it, they set the model, they set the limits, and they can change both without asking you. Your prompt and your text go to their service to be answered. What it remembers is the thread, and only while the thread is open. Some keep a longer history per user. Ask the plain question: if I close this and come back on Monday, what does it still know about me? A vendor who cannot answer that in one sentence has not built it. What it may do alone is answer. That is the safety of the category. It cannot send your invoice to the wrong client, because it cannot send anything. What it costs is a seat or a bundle of messages, and the number on the invoice is close to the number you budgeted. That is a real advantage of the deal and you should count it. How it fails is the confident wrong answer, given straight to a customer with your name at the top. The damage is not technical. It is that you now own a sentence you did not write. The fix people reach for is more grounding and more rules, and there is a point where you have paid for a worse copilot. ## Copilot: help inside the tool you already use What you install is a plugin, an add-on, or a feature switch inside a tool you already pay for. The tool is the point. A copilot with no host is a chatbot with a different price. Who runs the model is the vendor of that tool, and you rarely get a choice. Read where the text goes. Your draft, your sheet, your code and your mail are the input, and the input goes wherever their service is. What it remembers is what is on the screen and what the tool already knew. This is the whole trick of a copilot and it is why the good ones feel so much better than the chatbot in the other tab: the context is free, because it is already open. What it may do alone is edit the thing in front of you, with an undo. It suggests, you keep or drop it. Some now write to other systems too, and the moment they do, you are buying an agent and the word on the box has not caught up. What it costs is a seat, added to a seat you already pay. That is why a copilot is the easiest sale in this list and the hardest to measure. You will not see its cost as a line of its own. How it fails is drift. It is right most of the time, so you stop reading closely, and the one in twenty that is wrong goes in unread. Nobody notices for a month. The tradeoff is real and it is the price of the category: a tool that is useful enough to trust is a tool you will stop checking. ## Agent: it runs its own loop What you install is a service with keys. It needs access to the systems it acts on, and that access is the whole install. If setup is only a sign-in, it is a copilot with a new name. Who runs the model is either the vendor, on their key, or you, on yours. Find out, because the answer changes the bill by an order of magnitude in either direction, and it also decides whose limits you hit when the loop gets long. What it remembers is the run. A goal, the steps it took, and the results it got back. Most keep that for the length of the run and drop it. If you want it next week, ask where it is stored and whether you can read it without the vendor. What it may do alone is the only question that matters here, and the honest answer is: as much as its tools let it. An agent is a loop with a list of tools. Its reach is the sum of that list, not the sum of what it is meant to do. The OWASP Top 10 for LLM applications names this one directly as excessive agency, and splits it into three causes: too much function, too many permissions, and too much autonomy. What it costs is tokens, and the number moves with the work, not with your headcount. One loop can be twenty model calls or two hundred. Any agent you buy should be able to tell you what one run cost. If nobody can answer that, nobody is watching it. How it fails is the wrong move made quickly, and then made again. The loop does not know it went wrong, so it keeps going. Wrong twice is a bug and wrong four hundred times is an incident, and the gap between them is a few minutes. ## Operating system: named jobs, shared memory, and a gate What you install is the odd one. There is no new app. You add a config to a host you already use, and a set of named jobs shows up inside it. Nothing new on the dock, nothing new to log into. Who runs the model is the host you already pay. That is the defining trait of the category and it is easy to check: if the seller can keep serving you while your own model bill is zero, they are running it, and they are not this. What it remembers is meant to outlast the session. A line of work has things that stay true: who the reader is, what the offer is, what you refuse to say. An OS that forgets the constraint between two sessions is an agent with a folder. What it may do alone is draft and propose, and then stop at a line you drew. The gate is the product. Work that publishes, sends, spends or wipes should wait for a named person to say yes, and the record of that yes should exist afterward. What it costs is a flat price for the system and your own tokens for the work. You pay twice, in two places, and you should know that going in. The upside of that shape is that the seller has no reason to make the model chatty. How it fails is quieter than the others and worse to unpick. The system holds a constraint that was true in March and is not true now, and every piece of work it produces is neatly, consistently wrong. The failure of an OS is stale truth, not a stray action. ## Who runs the model, and why it shows up on your bill This is the cheapest question on the list and the one people skip. There are three answers and they are easy to tell apart. The vendor runs it on their key. You run it on your key, given to them. Or your host runs it, and nobody hands a key to anyone. If the vendor runs it, your price is flat and their margin moves with your use. That means they have a reason to keep answers short and a reason to move you to a cheaper model when costs bite. Neither is wrong. It is the shape of the deal and you should know it is there. If you hand over a key, you get the choice of model and you also get the bill for every retry you never saw. Ask what happens on a loop that does not end. Ask whether there is a cap, and whether the cap is yours to set. If your host runs it, the model is whatever your host runs today, and the seller is a config on the other side of a protocol. The MCP documentation is blunt that the protocol handles context exchange and says nothing about how the application uses a model, which is why this arrangement can exist at all. The host keeps the conversation, the server offers tools, and the tokens are spent where they were always spent. Ask it out loud, in these words: if I stopped paying my model provider tomorrow, does your product still work? The answer places the product on this axis with no room to wriggle. ## What it remembers: session, run, or store Memory is where the four categories separate most clearly, and where marketing pages are vaguest. There are three honest shapes and you can name the one you are being sold. Session memory lasts as long as the window is open. It is not a feature, it is the absence of one, and there is nothing wrong with that if the work is one question long. Run memory lasts as long as one job. The agent knows what it did four steps ago because the steps are in the prompt. It ends when the run ends. This is enough for a loop and not enough for a line of work. Store memory is the only one that survives you closing the laptop. It has a shape, it has a place, and someone can read it. The questions to ask are: where is it, can I read it without you, can I delete one thing from it, and what happens to it if I cancel. A quick test in a chat window: tell it a fact that matters, close everything, come back the next day and ask about it. If it knows, you have store memory. If it apologises, you have session memory and a marketing page that said otherwise. - Session: dies with the window. Fine for a single question. - Run: lives for one job. Fine for a loop with an end. - Store: survives. Ask where it is and who can read it. - The test: tell it something on Monday, ask on Tuesday. ## What it is allowed to do alone Every product in this map has a line between what it does on its own and what it asks you first. Find the line. It is the single most useful thing you can learn in a demo, and it is almost never on the pricing page. The OWASP Top 10 for LLM applications is the plainest public writing on this, and it is free to read. Its entry on excessive agency names three separate causes, which is useful because they have three separate fixes. Too much function: the tool can do more than the job needs. Too many permissions: the account behind the tool can reach more than the job needs. Too much autonomy: nobody has to say yes before something that matters happens. That split is worth carrying into a call, because a vendor will often answer one and leave the others. A read-only integration with an admin key is still a bad day waiting. A tightly scoped key attached to a tool that can do anything is the same bad day from the other side. The approval question is the third one and it is the one you can check yourself. Ask for a demo of a rejected action. Not an approved one, a rejected one. You want to see what the product does when the person says no: does it stop, does it retry, does it half finish, and is there a record of who said no and when. Public guidance points the same way. The NIST AI Risk Management Framework, which is voluntary and free, is organised around four functions: govern, map, measure and manage. None of them is a prompt. That is a slow way of saying the interesting part of an AI purchase is the part where a person is still in the loop on the things that matter, and where someone can tell you afterwards what happened. ## What it costs to run, beyond the sticker There are three bills and a product can have any two of them. The seat or the licence. The tokens. The people who now have to check the output. The third one is the one nobody quotes and it is often the biggest. A copilot that writes a draft you must read line by line has moved the work, not removed it. That can still be a good trade. It is not the trade on the slide. Token cost is the one that surprises finance, because it moves with volume and not with headcount. Ask for the shape of it: per message, per run, per document, per month. Then ask for the worst case, which is the number that shows up in the month you actually rely on the thing. The honest thing to say here is that we cannot tell you what any of this costs at your volume, and nor can anyone else before you run it. What you can do is insist that the product can show you its own usage, broken down by the unit of work you care about. A product that cannot show you that is a product nobody has had to justify yet. ## How to place a product in twenty minutes Run this on the thing you are looking at right now. Each step has something you see, and the thing you see is the answer. One: open the setup page and count what you install. A URL, a browser add-on, a service account with keys, or a config file on a tool you already run. Four different answers, four different categories. Two: look for a field that asks for your model key. If there is one, you run the model. If there is not, and the product still answers, they do. If the setup is a config on a host you already pay for, the host does. Three: tell it one durable fact. Not a task, a fact. Close the session. Come back tomorrow and ask. You now know whether memory is session, run, or store, and you know it better than the docs do. Four: ask for the list of things it can do without you. If the answer is a paragraph rather than a list, that is the answer. A product with a real gate has a list, because someone had to write the gate. Five: ask to see a rejection. Watch what happens after the no. Six: ask what one unit of work costs and what the worst unit last month cost. Silence here is information too. At the end of those six you will have placed it, and you will have six answers to compare against the next one. That is worth more than the category name, which was always the least reliable part of the page. - Say this: if I stopped paying my model provider tomorrow, does your product still work? - Say this: show me a run where the person clicked no, and show me the record of it. - Say this: what did one unit of work cost last month, and what did the worst one cost? - Say this: list what it can do without asking me. Not describe. List. - Say this: if I cancel, what happens to what it has learned about my company? ## Where this map breaks Products move between categories without changing their name. A copilot that gains the ability to write to a second system has become an agent in every way that matters to you, and the release note will call it an improvement. Re-run the six checks after a big update, not just before you sign. The map also says nothing about quality. A well built chatbot beats a badly built operating system on almost any day, on almost any work. The categories tell you what kind of risk and what kind of bill you are taking on. They do not tell you whether the thing is any good, and nothing in a category name ever will. And the boundaries are genuinely soft in one place: between an agent and an operating system. A single agent with a durable store and a hard approval gate is doing most of what an OS does. The difference is whether there is more than one named job and something that holds the constraint across them. If you only have one job, you may not need the other thing, and paying for it is paying for structure you will not use. Last limit, and it is ours: these six checks are the ones we found useful. They are not a standard, nobody audits them, and a determined vendor can answer all six well and still ship something you do not want. They narrow the field. They do not pick for you. ## Where Agentik sits on its own map Agentik {OS} is in the fourth column, and it is fair to hold us to the same six checks. What you install is a config on a host you already pay: Claude, Claude Code, Cursor, ChatGPT, Codex or Hermes. Who runs the model is that host. We never buy tokens, which also means we cannot promise you a bill we do not control. What it remembers is per project, so one OS can hold a separate store for each client. What it may do alone is draft and propose, and work that publishes, sends, spends or resets waits for approve. What it costs is $19.99 once for a single official OS, or $19 a month for three, $99 for ten and $199 for unlimited, plus your own model bill. The official systems today are Content OS, Growth OS, Librarian OS and Builder OS. The failure we hit is the one named above: a constraint that was true when it was written and is not true now. There is no clever fix for it in the product. Someone has to reread what the system believes. If that sounds like work, it is, and it is the part of this category nobody puts on a slide. /docs/mcp has the install side and /glossary has the 647 terms if a word in this piece was new. ## Four categories on the six checks a buyer can actually run | Check | Chatbot | Copilot | Agent | Operating system | | --- | --- | --- | --- | --- | | What you install | A tab or a widget | A plugin in a tool you pay for | A service with keys to your systems | A config on a host you already run | | Who runs the model | The vendor | The tool's vendor | The vendor, or you on your key | Your host | | What it remembers | The open thread | What is on screen | The run | A store per project, across sessions | | What it may do alone | Answer | Edit what is in front of you, with undo | Whatever its tool list allows | Draft and propose, then wait for a yes | | What it costs to run | A seat or a message bundle | A seat on top of a seat | Tokens that move with the work | A flat price plus your own tokens | | The failure you will hit | A confident wrong answer to a customer | Drift: right enough that you stop reading | The wrong move, repeated fast | A stale constraint, applied consistently | ## Sources - [OWASP Top 10 for LLM Applications: LLM06 Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) - [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) - [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [Model Context Protocol: architecture overview](https://modelcontextprotocol.io/docs/learn/architecture) ## FAQ ### What is the difference between a copilot and an agent? A copilot acts inside the tool you have open and waits for you to keep or drop each suggestion. An agent takes a goal, runs its own loop across systems, and stops when it decides it is finished. ### Is a chatbot just a worse agent? No, it is a different purchase with a different risk. A chatbot cannot act, so its worst case is a wrong answer, while an agent's worst case is a wrong action repeated before anyone looks. ### How do I tell which category a product is in? Count what you install, then find out who holds the model key. Those two answers place almost every product, and the setup page usually gives you both. ### What does an AI operating system add over an agent? More than one named job, a store that survives the session, and an approval line for anything that leaves the building. If you only have one job to automate, you may not need it. ### Who pays for the tokens? Whoever holds the key, and that is worth settling before you sign. If the vendor holds it your price is flat and their limits are yours, and if your host holds it the bill moves with your own use. ### Does the category tell me if the product is good? No. It tells you what kind of bill and what kind of failure you are taking on, and a well built product in a simpler category beats a badly built one in a grander category most days. # Choosing your AI host: the five questions that matter URL: https://agentik-os.com/blog/choosing-your-ai-host-the-five-questions-that-matter Published: 2026-09-19; updated: 2026-09-19 Five questions decide whether a host can run the tools you plan to install: remote MCP with OAuth, which machine opens the call to your server, what is still there after a restart, whether a non-coder can finish the setup, and the seat bill at your head count. Each one has a test you can run in ten minutes. Where a vendor does not write the answer down, this page says we do not know. ## The five questions, and why the order matters A host is the app that runs the model and pays for the tokens. Claude, Claude Code, Cursor, ChatGPT, Codex and Hermes are hosts. Most write-ups compare them on feel: which one is nicer to type into, which one gets the code right. If you plan to install tools into the host over MCP, feel is the last thing to test. Four of the five gates below are answered by the vendor's own docs plus one command. Every host claim on this page comes from the vendor page listed in the sources at the end, read on 19 September 2026. Where a page did not say, this article says we do not know. Ask them in this order. Each answer makes the next one cheaper to test. A host that cannot hold a remote MCP server with OAuth is out at gate one, and its seat price stops being your problem. A host that clears gate one but opens the call from the vendor's cloud changes what your network team has to sign off, which changes who is able to install it, which changes the number of seats you are really buying. The five are not equal. The first two cut hosts from the list. The third and fourth decide if the setup lives past the first week with other people in it. The fifth decides the bill. Work down the list in that order and you cut the field before you pay for a trial. - 1. Can it add a remote MCP server over HTTP, with OAuth, and no proxy you have to write and run? - 2. Who sees your data: which machine opens the call to your server, and what does the vendor say about training on what you type? - 3. Does it keep state between sessions, and which state: the server list, the token, or the chat? - 4. Can a person who never opens a terminal finish the setup, or does it end in a JSON file? - 5. What does a seat cost at your real head count, on top of the model tokens the host already bills? ## Question 1: can the host add a remote MCP server with OAuth? Support for MCP is three features wearing one badge. A host can start a local process over stdio, which is a command on your own machine. It can open a streamable HTTP call to a URL. It can also hand the job to the vendor's backend, which opens the call for you. The three are not swaps for each other. A server you buy or build will work with one of them and fail on the others. The server half of this is a spec, so you can hold a vendor to it. The MCP auth spec says a guarded server acts as an OAuth 2.1 resource server. It says the server MUST publish Protected Resource Metadata (RFC 9728), so a client can find the auth server on its own. It says the client MUST use Resource Indicators (RFC 8707), so the token it gets is bound to your server and cannot be replayed at some other one. It says both sides SHOULD do Dynamic Client Registration (RFC 7591), so that no human has to paste a client ID. What you are testing is the client half. Anthropic's Claude Code MCP page gives a one line add for an HTTP server, and a sign-in through a slash command in the session or a login command in the shell. OpenAI's MCP page for Codex lists streamable HTTP servers with bearer tokens or OAuth, and names both Client ID Metadata Documents and Dynamic Client Registration. Cursor's MCP page lists stdio, SSE and streamable HTTP, and its OAuth path wants a static client ID, with an optional secret, against fixed redirect URLs. Those are three different stories about the same word. The third one means a server that only does dynamic sign-up needs a client made by hand first. Ten minutes: open the host's MCP docs and search for the word http. If every example is a command with flags, the host starts local processes, and your remote server will need a bridge on each machine. Then search for oauth. If the only path is a token you paste into a header, the host can reach your server, but the key is now a long lived secret in a file, and rotating it is your job from then on. - Local process over stdio: the host starts a command. Fine for a tool that reads your disk, no use for a server a team shares. - Streamable HTTP from your own machine: the host opens the call. Your firewall sees your laptop. - Brokered by the vendor: the vendor's servers open the call. Your firewall sees the vendor. That is question 2. - A token in a header: it works today, and it is the thing you will forget to rotate next year. ## Question 2: who sees your data, and which machine opens the call? There are two data questions here and only the loud one gets asked. The loud one is training: does the vendor learn from what you type. The quiet one is routing: which IP shows up at your MCP server, and so which network line the setup has to cross. Anthropic answers the routing one in plain words. Its support page for custom connectors says that when you add one, Claude reaches your remote MCP server from Anthropic's cloud rather than from your own device, and that this holds for the web app, the desktop app, Cowork and the phone apps. A server behind your VPN will not connect, even though you can open it yourself, and the fix it names is to allow the vendor's IP ranges through your firewall. The same page says local MCP servers set up in the desktop config file are a separate path that does use your own network, and that this path is not there in Cowork or on the web. That one fact reorders a buying process. If your server is internal, a brokered host turns the setup into a firewall ticket, and that ticket is not yours to close. If your server is public and sits behind OAuth, the brokered path is usually the better one, because it gives you the same tools on a phone that you get on a laptop, and a local setup cannot do that. On training, read the page the vendor wrote for the plan you are on, not a summary of it. Anthropic's privacy page for the consumer plans frames model improvement as a thing you switch on, with a setting to change your mind, and says in its first lines that it covers the consumer plans and not the commercial ones. Cursor's security page says that with Privacy Mode on, it will not train on your data, and that new team members inherit the team setting. Both of those are about the host. Neither one says a word about the MCP server you install into it, which has its own terms and its own logs. Ten minutes: point the host at a server you own, even a stub that logs the call and returns a 401, and read the log. One line tells you the source IP, the user agent, and whether the host tries again after a failure. No doc page beats that. - Read the page for your plan. The same vendor has one set of terms for consumers and another for work accounts. - Log the first call. Source IP plus user agent answers the routing question in one line of text. - Ask what the tool vendor keeps. The host's terms do not bind the server on the other end of the call. - If your server is internal, get the vendor's IP ranges before you promise a date to anyone. ## Question 3: does the host keep state between sessions? State is three things and hosts treat them one way each. There is the server list, which is config. There is the token you get at the end of the OAuth flow. There is the chat itself, meaning what the model still knows about your work when you come back on Monday. Config is the easy one to check, because it is a file you can open. Claude Code names three scopes: a local one, a user one that follows you across projects, and a project one in a file at the root of the repo that you commit and share. Codex keeps its MCP config in one file per user, with a per project file for trusted folders, and its docs say the CLI, the IDE add-on and the desktop app all read the same file, so you can move between them without setting it up again. Cursor has the same split: one file in the project, one in your home folder. A shared file in git is what makes a team setup repeatable, and it is also how secrets get out. A shared file is a good thing when the server uses OAuth, because there is nothing secret in it. The same file with a token in a header puts a key in your repo history, where it stays after you delete the line. Chat state is the one people mean when they ask, and it is the one this page will not rank. Two products can put the word memory on two different things, and the same product can put it on two plans. Read the vendor page for the plan you hold, then test it rather than trust it. Ten minutes: add the server, run one tool, quit the host all the way, and open it again. Check three things in order. Is the server still listed. Does the first call go through with no new consent screen, which tells you the refresh token was kept. Does the model still know a fact you gave it yesterday, which tells you whether chat state is real or whether you are the memory. - Server still listed after a restart: the config is on disk or in your account. Expect this from every host here. - No second consent screen: the host kept a refresh token. Ask where it went, and whether it is in the OS keychain. - The model recalls yesterday: chat state is real. Test with a fact only you could have given it, not one it could guess. - Two machines, one account: set it up on a second device and see what carries over. Brokered hosts win this one. ## Question 4: can a non-developer install it? Ask this one out loud. It decides whether your setup reaches five people or fifty, and it is easy to skip when the person choosing lives in a terminal. Two of the six are terminal tools. Claude Code and the Codex CLI want a shell, and their MCP setup is a command or a file you edit. Cursor is a code editor, and its MCP setup is a JSON file in a folder, with a panel for switching servers on and off. Those are good surfaces for engineers and a wall for the rest of the company. The click paths are written down too, and they carry a gate of their own. Anthropic's support page on custom connectors says they are there on Claude, Cowork and Claude Desktop for the Free, Pro, Max, Team and Enterprise plans, that a Free user gets one custom connector, and that on Team and Enterprise only an Owner can add one to the org, after which each member connects to it on their own account. OpenAI's MCP page describes an Add server dialog in the ChatGPT desktop app and in the IDE add-on: a name, a choice of stdio or streamable HTTP, and an Authenticate button for the servers that need it. ChatGPT on the web is the one that catches people out. The same OpenAI page says ChatGPT on the web can use remote MCP tools that come from installed plugins, that it does not read the local Codex config file, and that admins decide which plugins and tools are there at all. If your plan was to send a colleague a URL to paste into the web app, read that page before you promise it. Ten minutes: send the setup steps to one person who does not write code, say nothing else, and watch. Count how many times they come back with a question. More than once and you are the setup process, and you will be the setup process for every new hire after them. ## Question 5: what does a seat cost at your team size? This page does not print per seat prices. They move, they differ by plan and by contract, and a price copied into an article is wrong within a quarter. The shape of the bill does not move, and the shape is the part people get wrong. You are buying two things that arrive as one number. There is the seat, which is what the host charges per person per month. There is the model use, which is either folded into the seat up to some limit, billed on its own against an API key, or both at once on two surfaces of the same product. Move work out of chat and into an agent loop and the seat count can stay flat while the model bill climbs, because a loop sends the context again on every turn. Write the sum down before you talk to anyone. Seats times price, plus the model spend you have now, plus the model spend the new work adds, minus the tool you stop paying for, if you stop paying for one. The third term is the one to measure, because it is the only one you cannot read off an invoice you already have. Ten minutes: open the vendor's pricing page for the tier you would really buy, find the two things that are metered, and write the seat price and the metered unit on one line. Then count the people who must act inside the host, and the people who only read what comes out. The second group does not need a seat. - Count actors, not head count. A person who reads the output does not need a seat in the host. - Ask what happens at the included limit: a hard stop, a slower model, or an overage. Each one is a different risk. - Check whether the admin controls sit on a higher tier than the seats do. Org-wide approval of connectors often does. - Price the exit. Config in files you own makes a move a copy. Config in an account makes it a migration. ## The ten-minute probe: what a compliant MCP server answers You do not need a host to test the server half of this, and you do not need an account. A compliant remote MCP server answers an unauthenticated call with a 401 and a WWW-Authenticate header pointing at its own metadata. Run this before you spend a seat. The example below uses Notion's public endpoint, which appears in Claude Code's own MCP docs. Step 1. Ask for the tool list with no token. The command is curl -s -i -X POST https://mcp.notion.com/mcp -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'. What you see: HTTP/2 401, and the header www-authenticate: Bearer realm="OAuth", resource_metadata="https://mcp.notion.com/.well-known/oauth-protected-resource/mcp", error="invalid_token". The shape of that header varies. We ran the same call against Stripe's endpoint and got the same pointer back with no realm and no quotes around it. The part that matters is resource_metadata, because that is the link the spec requires and the link the host will follow. Step 2. Fetch the URL from that header. You get a small JSON document with the resource, an authorization_servers list, and scopes_supported. If the resource value does not match the URL you just called, character for character, a host that checks the audience of its token will refuse to use it, and you have found the bug before it became a support thread. Step 3. Fetch /.well-known/oauth-authorization-server on the auth server named in step 2. Look for three fields. S256 in code_challenge_methods_supported, which is PKCE. A registration_endpoint, if you want dynamic sign-up to work. And resource_indicators_supported. A server with no S256 leaves an intercepted code usable on its own. Step 4. Now add the server in the host and watch the browser window it opens. The domain in the address bar during consent should be the auth server you read in step 2. If it is some other domain, stop and find out why before anyone signs in. Four minutes per server once the commands are in your shell history. It tells you more than any comparison table, this one included. It also works against a server you are building, which is the cheapest way to learn that your metadata document has the wrong resource URL in it. ## What each host documents today, and what we could not check The table at the end of this page holds only claims the vendor writes down, and the page each claim came from is in the sources. It does not score anything. Two hosts with the same cell can feel nothing alike in daily use, and that gap is not a thing an article can measure for you. One honest hole: Hermes. We could not find vendor docs on its MCP behaviour that we were willing to cite, so this page does not state what it supports. If Hermes is on your list, ask for the transport list and the OAuth behaviour in writing, then run the probe above from inside it. A second hole: every cell is what the page said on the day we read it. Host support for MCP has moved in both directions: Claude Code's own page now marks the SSE transport deprecated. Re-read the vendor page rather than trust a cell in a table, ours included. ## Failure modes when you install a server into a host These are the failures that look like a broken server and are really a host mismatch. Each has a symptom you can name before you file the bug against the wrong party. - The server never connects and the host shows no error. Cause: the host opens the call from the vendor's cloud and your server is on a private network. Proof: zero entries in your server's access log. - Consent works, then every call returns a 401. Cause: the token is bound to a resource that is not the URL the host calls, usually a trailing path that differs by one character. - It works for you and fails for a colleague. Cause: plan gating. On Team and Enterprise plans an Owner has to add the connector to the org before members can connect to it. - Tools show up, then vanish after a restart. Cause: the server was added in a project scope and the other person opened a different folder. - The model ignores a tool that is right there in the list. Cause: a name and a description that read like three other tools. That is a server problem, and no host setting fixes it. - It works in the terminal client and fails in the web client of the same vendor. Cause: the two surfaces read different config, which the vendor documents and nobody reads. ## The tradeoff: one host for everyone, or one host per job Standardising on one host is cheaper to run and easier to support, and it costs you the thing each host is good at. A terminal host is better on code because it sits in the repo. A brokered host is better at reaching a person on a phone. Picking one is picking which group gets the worse tool, so pick it out loud rather than by accident. Two hosts costs the other way. You keep two configs, two OAuth grants per person, and you answer the same security questionnaire twice. What saves it is that a remote MCP server is one server either way, so the tools do not double when the hosts do. If you go that way, treat the server as the system of record and the host as a thing you can throw away. That is also the cheapest way to survive a host you stop liking. The limit of all five questions: they test the plumbing, not the work. A host can pass every gate and still be wrong for you, because the model behind it is weak at your task, because the team will not use it, or because the one feature you need sits on a plan you cannot buy. Use the questions to cut the list, then run real work in the last two for a week. A second limit: none of this predicts how a host behaves when things break. The probe says a server answers correctly right now. It says nothing about what the host does when a tool hangs mid-task, and that behaviour differs enough between hosts to matter. Point the host at a server that sleeps for two minutes and read what it tells the user. ## Where Agentik fits, in one paragraph Agentik {OS} sells operating systems that install into the host you already pay for, over one public MCP endpoint at https://mcp.agentik-os.com/api/mcp, with OAuth 2.1 and PKCE. The hosts are Claude, Claude Code, Cursor, ChatGPT, Codex and Hermes. The host runs the model and pays the tokens. Agentik never buys tokens, which is exactly why the five questions above are yours to answer and not ours to answer for you. For the per host steps rather than the choice, /docs/mcp has them. The honest cost of that design: a host that fails question one cannot run our OS either. We sit on your side of the table on this one, which is why this page cites vendor docs instead of ranking vendors. ## What each host documents about remote MCP servers | Host | What you configure | Remote HTTP and OAuth, per the vendor docs | Where the config lives | | --- | --- | --- | --- | | Claude apps (web, Desktop, Cowork) | A custom connector in settings | Documented on Free, Pro, Max, Team and Enterprise. Free is limited to one custom connector. On Team and Enterprise an Owner adds it | Your Claude account. The call is made from Anthropic's cloud, not your device | | Claude Code | claude mcp add --transport http | Documented. OAuth through /mcp in the session, or claude mcp login | ~/.claude.json for local and user scope, .mcp.json in the project for the shared scope | | Cursor | An mcp.json entry | Documented for SSE and streamable HTTP. OAuth uses a static CLIENT_ID, an optional CLIENT_SECRET, and fixed redirect URLs | ~/.cursor/mcp.json globally, .cursor/mcp.json per project | | Codex (CLI, IDE add-on, ChatGPT desktop app) | codex mcp add, or the Add server dialog | Documented for streamable HTTP, with bearer tokens, OAuth, Client ID Metadata Documents and Dynamic Client Registration | ~/.codex/config.toml, or .codex/config.toml in a trusted project. The three clients share it | | ChatGPT on the web | Installed plugins, not a URL you paste | Documented as remote MCP tools supplied by plugins. The local Codex config is not read | The workspace. Admins control which plugins and tools are available | | Hermes | This article does not know | We found no vendor docs we could cite. Ask for them in writing | This article does not know | ## Sources - [Model Context Protocol specification: Authorization](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) - [Claude Code documentation: MCP servers, scopes and OAuth](https://code.claude.com/docs/en/mcp) - [OpenAI documentation: MCP in Codex and ChatGPT](https://learn.chatgpt.com/docs/extend/mcp) - [Cursor documentation: Model Context Protocol](https://cursor.com/docs/context/mcp) - [Anthropic support: custom connectors using remote MCP](https://support.anthropic.com/en/articles/11175166-getting-started-with-custom-connectors-using-remote-mcp) ## FAQ ### Which AI host should I choose for MCP servers? The one that documents remote HTTP transport with OAuth, opens the call from a place your network allows, and can be set up by the people who will use it. Run the four-minute probe on this page against your server, then run real work in the last two hosts for a week. ### Can I add a custom MCP server to ChatGPT on the web? The docs say ChatGPT on the web uses remote MCP tools supplied by installed plugins, and that it does not read the local Codex config file. The desktop app and the Codex CLI do let you add a server directly, and they share one config file. ### Does a remote MCP server need OAuth? The MCP spec makes authorization optional, but once an HTTP server does authorize, it requires Protected Resource Metadata and tokens bound to that resource. A static token in a header works on several hosts and becomes a rotation problem you own forever. ### Why does my MCP server work locally but not when the host connects? Check which machine opens the call. Anthropic documents that custom connectors reach your server from its cloud rather than from your device, so a server behind a VPN or a firewall stays dark until the vendor IP ranges are allowed through. ### Is it worth running more than one host? It is when a terminal host serves the engineers and a click-through host serves everyone else, because the remote MCP server stays one server either way. The cost is two configs, two OAuth grants per person, and the same security review twice. # Cost control for agent systems: where the tokens actually go URL: https://agentik-os.com/blog/cost-control-for-agent-systems-where-the-tokens-actually-go Published: 2026-09-19; updated: 2026-09-19 An agent bill is six line items, not one: the system prompt, the tool schemas, the tool results, the retries, the fan-out to other agents, and the history you resend on every turn. Five of the six can be measured today with a token counter and the usage object you already get back. This page shows how to measure each one and which fixes pay, in order. ## Where the tokens actually go in an agent system The obvious move is to compare prices per million tokens and pick a cheaper model. That changes the price of a token. It does not change how many tokens a task needs, and in an agent loop the count is what moves the bill. Almost none of that count is the words a person typed. Every price and limit in this article is quoted from the vendor page named beside it, read on 19 September 2026. The only measurement of our own is two payload sizes from our own server. There is no benchmark here, no customer result and no adoption number, because we have not run those. Here is the shape of a single agent turn. The host sends the system prompt, the full schema of every tool the agent can call, the whole conversation so far, and the result of the last tool call. The model writes a short reply and maybe one more tool call. Then the loop runs again, and everything above the new line is paid for a second time. A ten step task does not cost ten times one message. It costs the sum of ten growing prompts. That is why the six line items below are worth separating. Each one grows for a different reason, each one is measured a different way, and the fixes are not interchangeable. The order here is the order to read them in, not the order of size, because the size depends on your system. One number of our own, measured on our own server by weighing the response payloads. On Growth OS, which compiles 48 agents, the pack our talk tool returns for a single conversation turn is about 2 KB. A full read of the agent roster is about 110 KB. Same question, two ways of answering it, and the gap is the bytes that reach the model. That is the difference between answering from a compact pack and letting the host read everything first. - System prompt: fixed size, paid on every request, every agent, every turn. - Tool schemas: grow with the number of tools, paid on every request whether or not a tool is used. - Tool results: the most variable of the six. One roster read can outweigh the whole conversation. - Retries and failed calls: pay the full prompt again for zero progress. - Fan-out: each sub-agent re-pays its own system prompt and schemas before it does any work. - History: the conversation is resent on every turn, so a long task pays for its own past repeatedly. ## The system prompt and the tool schemas are a subscription A system prompt is written once and billed forever. So is every tool schema. If your agent has forty tools, the name, description and full input schema of all forty are in front of the model on every single request, including the ones where the model just says yes. This line item is invisible. It never appears in a log, and nobody watches a tool schema scroll past. Measure it once and the 300 word tool description stops looking free. The Claude API has a token counting endpoint that takes the same body as a real request, tools included, and returns the input token count without running the model. Send your request body twice, once with the tools array and once without it. The difference is the schema tax you pay on every call. Two traps here that come from the vendor docs. First, Anthropic's token counting page at platform.claude.com/docs/en/build-with-claude/token-counting says the count is an estimate, and that the endpoint rejects some inputs the Messages API accepts, including server tools and the MCP connector, so for those you have to read the usage object on a real response instead. Second, the same page says Claude 4.7 and later models use a newer tokenizer, where the same input text produces roughly 30 percent more tokens than on earlier models, and tells you to recount against the model you plan to use. A budget carried over from an older model can be off by roughly that much before you start. The fix is not to write shorter prompts. The fix is caching. Anthropic's pricing page at platform.claude.com/docs/en/about-claude/pricing lists a cache hit at 10 percent of the base input price, a five minute cache write at 1.25 times the base price, and a one hour write at twice the base price. The same page states the break-even: a five minute cache pays for itself after one read, a one hour cache after two. It lists Claude Opus 5 at 5 dollars per million input tokens, 6.25 for a five minute write, and 0.50 per million on a cache hit. Caching works on prefixes, so the order of your request decides whether it works at all. Anything that changes invalidates everything after it. A timestamp in the system prompt, a tool list that is built by iterating a hash map in a different order each run, or a user name injected at the top, and your cache read rate is zero while you keep paying write prices. - Put the stable content first: system prompt, then tools, then history, then the volatile part of the turn. - Freeze the tool order. Sort it. A set iterated in random order is a cache miss you will never notice. - Watch cache_read_input_tokens in the usage object. Zero across repeated calls means something upstream is changing. - Delete tools the agent never calls. A schema you do not use is rent you pay on every request. ## Tool results: the line item that keeps getting paid A tool result goes into the conversation and stays there. It is paid on the turn it arrives, and again on every turn after that, until something removes it. One careless tool can therefore outweigh every other line item in the loop. The usual shape of the mistake is a list endpoint. An agent asks what is available, and the tool answers with everything: every record, every field, every id. That tool is simple to write, and its result is then carried by every turn after it. The two payload sizes we weighed on our own server are the example: about 2 KB for a pack that answers the turn, against about 110 KB for the full 48 agent roster. Same system, two different tools. Two hosts cap this by default, which is itself informative. Anthropic's Claude Code MCP page at code.claude.com/docs/en/mcp documents a warning threshold at 10,000 tokens of tool output and a default limit of 25,000, with results above the limit written to a file instead of the conversation, and an environment variable to raise the ceiling. It also documents a per tool annotation a server can send in its tools list to raise its own result size, up to a maximum of 500,000 characters. OpenAI's MCP page at learn.chatgpt.com/docs/extend/mcp documents a per tool output token limit in the Codex config, applied before what it calls the standard 20 percent serialization allowance. Read those caps as a warning rather than a solution. A truncated tool result is a tool result the model cannot use. The agent will call the tool again with different arguments, which costs a full turn, or it will answer from the part it saw, which is worse. Fix the tool, and use the cap as a tripwire that tells you when a tool has regressed. The fix that works is a pack: the tool decides what matters for this turn and returns that, with a handle to fetch the rest if it is needed. This moves work from the model to your server, which is the trade. Your server now has to be smart about what to include, and when it guesses wrong the agent needs a second call. Whether the trade pays depends on how often the guess is wrong. One extra call now and then beats a roster read on every turn. A pack that misses half the time does not. - Cap output at the source, in the tool, not at the host. The host cap truncates. The tool can summarize. - Return identifiers plus a fetch tool, rather than whole records the model will mostly ignore. - Strip fields no agent reads: timestamps, internal flags, empty arrays, repeated parent objects. - Log the byte size of every tool result. The worst one is not the one you would guess. ## Retries and failed tool calls: the cost that never shows up in the UI A failed tool call costs exactly as much as a successful one. The model still read the prompt, the tools and the history to produce the call. Then it reads the error and tries again, which costs all of that a second time. Three failures in a row is four turns of input tokens for one step of progress. Timeouts are the expensive variant, because the host waits and then bills. OpenAI's MCP page at learn.chatgpt.com/docs/extend/mcp documents a default tool timeout of 60 seconds per call and a default startup timeout of 10 seconds per server, both configurable per server. A tool that sits at 59 seconds and then fails pays full price for that turn, produces nothing, and then gets retried. The cheapest fix is a schema the model cannot get wrong. Enum the values it must choose between rather than describing them in prose. Mark the required fields. Give one example in the description, not four. When a tool fails twice with the same error, read the argument shape before you touch the prompt. An argument shape failure is fixed in the schema. The second fix is making a retry safe. If a call can be repeated without doing the work twice, the agent can retry without you worrying, and you can fail fast instead of holding the connection open. If a call cannot be repeated safely, it should not be retried automatically at all, and it should be behind a human approval before it runs. - Count turns per completed task, not tokens per request. Retries show up there and nowhere else. - Log the error string of every failed tool call, then group them. A short list of distinct strings is normal, and each one is a fix. - Fail fast on tools that cannot succeed. A 60 second timeout on a dead endpoint is a full-price turn. - Return a usable error: what was wrong and what to send instead. An error the model can act on prevents a third call. ## Multi-agent fan-out multiplies the prefix, not just the work Splitting a job across several agents is a good idea for quality and a dangerous one for cost. Each agent starts with its own system prompt and its own tool schemas. A fan-out to six sub-agents pays six prefixes before a single useful token is produced, and their answers all come back into the parent conversation, where they are paid for again on every later turn. The arithmetic to do before building one: prefix size times the number of agents, plus the tokens each one produces, plus the cost of their combined output sitting in the parent context for the rest of the task. If the prefix is large and the work per agent is small, a fan-out is a way to spend more money for the same answer. Caching does not soften this, because a cache is tied to one exact prefix and one model. Six agents with six different system prompts are six separate caches, each one cold on the first call. Six agents that share one prompt and differ only in their instructions can share the prefix, which is a design decision you make once and keep. The rule we use: fan out when each branch reads a lot and returns a little. Research across five sources fits that shape, because the reading stays inside the sub-agent and only the conclusion comes back. Splitting one short task across five agents does not fit it, and the bill says so. ## Long conversations re-read themselves The API is stateless. Every turn resends the whole conversation. That means the cost of turn twenty includes everything from turns one to nineteen, and the total cost of a task grows faster than the number of steps. A demo of three turns and an hour of real work have very different shapes for this reason. The same effect hits files. An agent that reads a large file, works for ten turns, then reads the same file again because it does not trust its own summary has paid for that file twice in full, plus the cost of carrying the first copy through all ten turns in between. Three mechanisms bound it, and they do different things. Caching makes the resent history cheap rather than free. Dropping old tool results removes them from the conversation. Summarising old turns replaces them with shorter text. Hosts and APIs give these different names, so check what yours calls them. The last two lose information, so they are decisions about what the agent may forget, not free wins. Cache lifetime matters here in a way that is easy to miss. With a five minute cache, a developer who reads the last answer, thinks for ten minutes, and then replies has let the cache expire. The next turn pays write prices again on the whole history. If your usage pattern is bursty, the longer cache lifetime that Anthropic's pricing page lists at twice the base write price can be the cheaper option, and the break-even it states is two reads. - Measure the token count of turn one and turn twenty of the same task. The ratio tells you how bad the growth is. - Cache the history prefix on long tasks. It is the difference between paying full input price and 10 percent of it. - Have the agent write its conclusions into a compact note it can reread, rather than rereading the source. - Decide what the agent may forget before you turn on anything that edits or summarizes context. ## How to measure all six in an afternoon This is the part that pays. Do it once on a real task, in this order, and you will know which of the six line items is yours. What you need is a token counter, the usage object from the responses you already get, and somewhere to write six numbers down. Step 1. Baseline the prefix. Take a real request body and send it to the token counting endpoint: curl -s https://api.anthropic.com/v1/messages/count_tokens -H "x-api-key: $ANTHROPIC_API_KEY" -H "anthropic-version: 2023-06-01" -H "content-type: application/json" -d @request.json. What you see: a JSON object with an input_tokens field. Write that number down. Step 2. Split the prefix. Copy request.json to no-tools.json, delete the tools array, and count it again. The difference between the two counts is the tool schema cost you pay on every request, forever. Divide it by the number of tools to find out which ones are worth trimming. Step 3. Weigh the tool results. Run the task once with logging on every tool return, and record the byte size of each result. Sort that list. The top entry is usually the thing to fix first, and it is usually a list call. Step 4. Read the usage object from a real run. On the Claude API each response reports input_tokens, output_tokens, cache_creation_input_tokens and cache_read_input_tokens. Sum them per task rather than per request. If cache_read_input_tokens is zero across repeated runs of the same task, your cache is not working, and that single fact is often worth more than every other change on this page. Step 5. Count turns per completed task. Not requests, not tokens: completed tasks and the turns they took. Then look at how many of those turns produced a failed tool call. That is your retry tax, expressed in a unit you can act on. Step 6. Put the six numbers next to each other and fix the largest one. Then measure again, because the second largest is rarely what it was before you started. The honest limit of this procedure: a token count is not a bill. Cached reads, batch discounts and different models are all priced differently, so the counts tell you where the tokens are, and the pricing page tells you what they cost. Keep the two separate in your head or you will optimize the wrong number. ## The interventions that work, in order of payoff Do these in order. Each one is cheaper to try than the one after it, and the early ones cost you nothing in quality, which is the part that matters when someone asks why the answers got worse. First, cache the stable prefix. It is a configuration change, it does not alter a single word of output, and on repeated work it turns the largest fixed cost into a tenth of itself. Verify it with the usage object rather than assuming it worked. Second, fix the loudest tool. One tool returning a full roster on every call can outweigh every other line item combined. Return a pack sized to the question, keep a fetch tool for the rest, and put a size check in your own code so a regression is caught before the invoice catches it. Third, cut the schema tax. Delete unused tools, shorten descriptions to the sentence the model actually needs, and move the long explanation into the server where it costs nothing per request. Fourth, batch what is not interactive. Anthropic's pricing page states the Batch API is a 50 percent discount on both input and output tokens, and that it combines with caching. Overnight jobs, backfills and bulk classification belong there. Anything with a person waiting does not. Fifth, and only now, touch the model and the reasoning effort. This is the first lever that trades quality for money, which is why it is fifth and not first. Judge it on cost per completed task, because a cheaper model that needs three attempts is not cheaper. ## What does not work, and what this does not solve Swapping to a cheaper model as the first move is the most common mistake. It changes the price of every token while leaving the number of tokens untouched, and if the cheaper model needs more turns to finish the same task, the bill goes up while the dashboard says the rate went down. Compressing prompts by hand is the second. Rewriting a system prompt to save 200 tokens is a day of work that caching would have made irrelevant. Do the caching first, then decide whether the prompt is still worth editing. Counting tokens instead of tasks is the third. A dashboard of tokens per day cannot tell you whether the work got done. Cost per completed task is the only number that survives a change in model, prompt or workflow, and it is the only one worth putting in front of a finance team. What none of this solves: if your agent is slow because a person has to approve every step, tokens are not your bottleneck and no amount of profiling will help. The same is true when the real cost is an engineer rerunning a broken pipeline. Measure where the hours go before you optimize where the tokens go. A second limit worth naming: every number on this page that is not ours comes from a vendor pricing or docs page, and those change. The multipliers, the caps and the discounts have all moved before. The method holds; recheck the numbers against the pages in the sources before you build a budget on them. ## Where Agentik fits, in one paragraph Agentik {OS} installs on the host you already pay for, and the host runs the model and pays the tokens. We never buy your tokens, so a cheaper pack is not a cheaper invoice for us, it is a cheaper invoice for you. That is the reason the talk tool exists: it answers a normal conversation turn and returns a pack of about 2 KB on Growth OS instead of the roughly 110 KB the full 48 agent roster costs to read. Work that publishes, sends, spends or resets waits for a human approval, which also caps the cost of a wrong turn. The honest limit of our own design: a pack is a guess about what this turn needs. When the guess is wrong the agent asks again, and that second call costs a turn. We think that trade is right for conversation and wrong for a task that genuinely needs the whole roster, and when you need the whole thing you should read the whole thing. ## Cost drivers, how to measure each one, and the fix | Cost driver | How to measure it | The fix | | --- | --- | --- | | System prompt | Count tokens on a request body with an empty messages array | Cache the prefix and keep it byte stable. Do not put a timestamp in it | | Tool schemas | Count the same body twice, with and without the tools array, and subtract | Delete unused tools, shorten descriptions, move the long explanation server side | | Tool results | Log the byte size of every tool return for one full task, then sort | Return a pack sized to the turn plus a fetch tool, not the whole list | | Retries and timeouts | Turns per completed task, and the count of failed tool calls inside them | Enums and required fields in the schema, fail fast, return errors the model can act on | | Fan-out | Prefix tokens times the number of sub-agents, before any work is done | Fan out only when a branch reads a lot and returns a little. Share one prefix where you can | | History re-reads | Compare the input token count of turn one and turn twenty of one task | Cache the history, note conclusions instead of rereading sources, decide what may be forgotten | ## Sources - [Anthropic: model pricing, cache multipliers and the Batch API discount](https://platform.claude.com/docs/en/about-claude/pricing) - [Anthropic: token counting endpoint, estimates and tokenizer changes](https://platform.claude.com/docs/en/build-with-claude/token-counting) - [Anthropic: prompt caching, prefixes and cache usage fields](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) - [Claude Code: MCP tool output limits and per tool result size](https://code.claude.com/docs/en/mcp) - [OpenAI: Codex MCP configuration, tool timeouts and output token limits](https://learn.chatgpt.com/docs/extend/mcp) ## FAQ ### What does an AI agent actually cost per task? It is the sum of every prompt in the loop, not the price of one message, because the system prompt, the tool schemas and the whole history are resent on every turn. Measure cost per completed task rather than per request, since that is the only number that survives a change of model or prompt. ### How do I measure how many tokens my tool schemas use? Send the same request body to a token counting endpoint twice, once with the tools array and once without it, and subtract. That difference is paid on every request whether or not a tool gets called. ### Does prompt caching actually save money? Anthropic's pricing page puts a cache hit at 10 percent of the base input price, with a five minute write at 1.25 times base, so a cached prefix pays for itself after one read. The catch is that any byte change in the prefix invalidates it, so verify with the cache read field in the usage object instead of assuming. ### Should I switch to a cheaper model to cut agent costs? Not first. Caching, tool output size and schema hygiene cost you nothing in quality, and a cheaper model that needs extra attempts can raise the bill while lowering the price per token. ### Why do my MCP tool results get truncated? Hosts cap them. Claude Code documents a 25,000 token default limit on tool output with a warning at 10,000, and Codex documents a per tool output token limit in its config. Treat the cap as a signal that the tool returns too much, not as the fix. # Fine-tuning or context: which problem are you solving URL: https://agentik-os.com/blog/fine-tuning-or-context-which-problem-are-you-solving Published: 2026-09-19; updated: 2026-09-19 Fine-tuning changes how a model behaves. Retrieval changes what it knows at the moment you ask. If you are picking between them for a support, research or internal-docs assistant, start from the broken output: this piece names the five ways an answer goes wrong, maps each one to the fix that matches it, and gives you three cheap tests that tell them apart in an afternoon. ## Fine-tuning vs RAG: which failure are you fixing Start from the broken output, not from the method. There are five ways a model output can be wrong, and each one has an owner. It does not know a fact, so the fix is retrieval. It knows the fact and says it in the wrong shape, so the fix is format. It says the right thing in the wrong voice or skips a step, so the fix is behaviour. It is right and slow, so the fix is latency. It is right and expensive, so the fix is cost. Fine-tuning is good at two of those five: format and behaviour. It is weak at the first one, facts, and that is the one people buy it for. Feeding a model a thousand pages of your handbook as training data does not give it a reliable memory of the handbook. It gives it the sound of the handbook, which is worse than not knowing, because the answers now look right. Retrieval is good at the first one and does nothing for the other two. Put the right page in the prompt and the model will use it. It will still write in a voice you did not ask for, and it will still skip the step you told it about once, three thousand tokens ago. So the question is never which method is better. The question is which of the five failures you have, measured on real outputs, before anyone opens a training script. - Wrong fact, right shape. Cause: the fact was not in the prompt. Fix: retrieval. - Right fact, wrong shape. Cause: no schema, or a schema said once in prose. Fix: ask for structured output, then tune if it still slips. - Right shape, wrong voice, or a step left out. Cause: behaviour. Fix: show it examples first, then tune if the examples get long. - Right and slow. Cause: a long prompt, or too many hops. Fix: cache, cut, or move behaviour into weights. - Right and dear. Cause: a big model doing a small job. Fix: a small model tuned on the big one's outputs. ## What fine-tuning actually changes inside the model Fine-tuning takes a set of example exchanges and nudges the weights so the model is more likely to produce that kind of output. The unit is a sample, not a document. A sample is an input and the output you wanted, in the format the model will see at run time. That shape matters more than people expect. If your training file is full of documents rather than exchanges, you are teaching the model a style of text, not a job. Style is what it will learn. A small set of samples that match the real task beats a large pile of handbook pages, and the reason is not scale, it is that only one of the two sets contains the thing you want repeated. The common cheap method is a low-rank adapter, from the LoRA paper in the sources below: a small set of extra weights trained on top of a frozen base. It cuts the cost and the storage and it lets you keep a few adapters around. The OpenAI fine-tuning guide in the sources shows the hosted version of the same idea, down to the file format. It does not change the shape of the problem. You still need samples, and the samples are still the hard part. One cost that surprises people: a tuned model can get worse at things you did not train on. The field calls it catastrophic forgetting, and in practice it shows up as a model that now writes your ticket summaries perfectly and can no longer do the arithmetic it used to do. That is why an eval set covering the old behaviour, not just the new one, is part of the price of the method. The file itself is plain. One line per exchange, in the same chat format the model answers in, which for a hosted service reads like the block below. If you cannot write two hundred lines of that by hand or harvest them from work you already approved, you are not ready to train. - {"messages": [ - {"role": "system", "content": "You are a support triage agent."}, - {"role": "user", "content": "Card declined on renewal, third time."}, - {"role": "assistant", "content": "{\"queue\": \"billing\", \"severity\": 2}"} - ]} ## What retrieval changes, and where it breaks Retrieval augmented generation, from the 2020 paper in the sources, means one thing: find the text that answers the question and put it in the prompt before the model answers. Nothing is learned. Nothing is stored in the model. Change the document at noon and the answer changes at noon, which is the whole reason to use it. It breaks in four places, and all four look like the model being stupid. The chunk boundary cuts a table in half, so the model reads a column with no header. The ranker returns the right topic and the wrong version, so you get last year's policy stated with confidence. The question does not share words with the answer, so the search finds nothing and the model answers from memory anyway. Or the text is there and buried in the middle of a very long prompt, with no label saying what it is, so the model treats it as background. Here is the quick way to see which half you are in. Open one bad answer. Look at the text the search put in the prompt, and ask if the fact was in it. If the fact was there and the answer is still wrong, the model is the problem. If it was not there, the search is the problem, and the model did what it could with what it had. That one check splits the work in two and it takes a minute. None of those get better with fine-tuning. Some of them get worse, because a tuned model is more sure of itself. If your team is arguing about tuning and nobody has read the retrieved chunks for ten bad answers, stop the argument and go read the chunks. That single hour reorders most of these debates. - Chunking: split on structure, not on a fixed character count. Keep the heading with the body. - Ranking: filter by date and by version before you rank by how close the text looks. Right topic, wrong year is the classic bad answer. - Recall: the question rarely uses the words the document uses. Run keyword and vector search together, and take the union. - Placement: put the retrieved text where the model reads it, and say what it is, not just paste it. - Scope: an agent that can see more than the user can is a bug, not a feature. Filter by who is asking. ## Symptom to fix: a table you can run against your own logs Take ten bad outputs from last week. Real ones, from real users, not the ones you made up to test with. Put each one in a row of this table and see where they land. If eight of them land in the retrieval column, your fine-tuning project is a way to avoid fixing the index. Do it on paper. One row per bad output. What you saw. What went wrong. What the row says to fix. Ten rows take half an hour and they end most of the fight, because the pile is rarely even. It is eight of one kind and two of the other. The eight is the work, and the two can wait. This is a diagnosis aid, not a law. Two rows can be true at once, and the right order then is to fix the cheap one first and re-measure, because the second problem is often smaller than it looked while the first one was still there. ## Why teams reach for fine-tuning when the real problem is retrieval The first reason is honest confusion. The symptom for a missing fact and the symptom for a missing behaviour are the same sentence: the model does not know our business. Said out loud, that sentence points at training, because training is what we do to people who do not know things. The machine does not work that way, and the phrase hides the difference. The second reason is that tuning feels like ownership. A fine-tuned model is a file with your name on it. An index is plumbing, and plumbing does not feel like a moat. That feeling has cost more quarters than any technical mistake on this page, because it survives the evidence: teams keep a tuning project alive after the tests say retrieval was the problem, since cancelling it means admitting the asset was never an asset. The third reason is that prompt work has a bad name. It sounds like fiddling. It is fiddling, for about a day, and then it is a versioned file with a test set behind it, which is the same discipline as a training run at a tenth of the cost. Teams skip the day of fiddling and buy the quarter of training. The tell is the sentence people use to justify it. If the sentence is we need the model to know our data, you have a retrieval problem. If the sentence is we need the model to always answer in this exact shape, and the examples in the prompt are now longer than the prompt itself, you have a real case for tuning. - The words to watch: we need it to know our data. That is a retrieval line, not a training one. - Also watch: it has to come out in this exact shape, every time. That one can be a real tuning case. - A tuned model is a file with your name on it. An index is a pipe. Both are work. Only one of them feels like an asset. - Ask who will run the next training job in a year. If no one can name a person, do not run the first one. ## Three cheap tests that tell you which one you need Run these in an afternoon before you spend a quarter. Each one has a result you can read without any tooling, and each one rules something out. Test one, the paste test, separates knowledge from everything else. Take a question the system got wrong. Find the document that holds the answer by hand. Paste it into the prompt and ask again. If the answer is now right, you have a retrieval problem, full stop. No amount of tuning will fix it, because the model already proved it can use the fact when the fact is present. Test two, the repeat test, separates format from behaviour. Send the same input twenty times at your normal settings. If the content is right every time and the shape moves around, that is a format problem, and structured output or a schema fixes it in an hour. If the shape holds and the content drifts, that is behaviour, and it is where examples and then tuning belong. Test three, the examples test, sizes the tuning case. Put three good examples in the prompt. Measure. Put ten. Measure again. If ten examples get you most of the way and the prompt is still a sane size, you do not need tuning yet, you need a prompt in a file with a test set. If the gain only arrives past thirty examples, and the prompt is now so long it costs real money on every call, that is the signal to move the behaviour into weights. - Test one, paste the source doc into the prompt. Right answer means a retrieval problem. - Test two, send the same input twenty times. If the shape moves and the content holds, it is format. If the shape holds and the content moves, it is behaviour. - Test three, try three examples, then ten, then thirty. If the gain flattens early, keep the prompt and skip the training run. - Write the result of each test down. The argument restarts in six weeks and the notes end it faster. ## What each one costs to keep alive after launch Both methods have an upkeep bill and neither vendor page leads with it. The shapes are different, and the difference decides more cases than the build cost does. A fine-tune ages against the model. When the provider ships a better base model, your tuned adapter is stuck on the old one until you run the job again, and a tuned old model can end up behind an untuned new one. So the real cost is not the training run, it is the promise to redo the training run, keep the dataset alive, and re-score the same eval set every time the ground moves. A retrieval system ages against your documents. It needs a freshness path, a delete path, and permissions that follow the user rather than the index, which is the part most teams add after the first incident. Change the embedding model and you re-embed everything. Add a reranker and you buy accuracy with latency, and the size of that trade is something to measure on your own data rather than take from anyone's table, this one included. The honest summary: tuning costs you a standing commitment to retrain, retrieval costs you a standing commitment to keep an index true. If you cannot staff one of those commitments, pick the other one, whatever the accuracy numbers say. - Fine-tune upkeep: keep the data set alive, run the job again each time the base model moves, score the old behaviour as well as the new one, version the adapters, and serve them. - Retrieval upkeep: pull the docs in, keep them fresh, honour a delete, filter by who is asking, re-embed the lot when the model changes, and score the search step on its own. - Shared: an eval set of real cases. Without it, neither method can tell you whether a change helped. - Shared: a per-run trace with the retrieved text in it. Bad answers are unreadable without it. ## When fine-tuning is the cheaper answer, not the fancier one There are cases where tuning is plainly right, and they share a trait: you are paying for the same tokens over and over to teach the model something that never changes. The first is a strict output format at volume. Classification, routing, extraction into a fixed schema. The job is narrow, the shape never moves, and a tuned small model can do it at a fraction of the price of a large one reading a long instruction each time. The second is a voice or a policy that takes many examples to pin down. When the prompt carries fifteen examples on every call to hold the style, those examples are rent. Tuning converts the rent into a one-off payment plus upkeep, and the break-even depends on your call volume, which you can work out from your own bill rather than from anyone's table. The third is latency inside a tight budget. A shorter prompt is a faster first token. If you have squeezed the prompt and cached what can be cached and the budget is still missed, moving stable behaviour into weights buys you room that no prompt trick will. The tradeoff in all three: you gain a cheap, fast, consistent model and you lose the ability to change its behaviour in five minutes. A prompt edit ships in a commit. A behaviour change in a tuned model ships in a training run, a scoring pass, and a deploy. Teams that iterate weekly on what the agent should do usually find that trade bad, even when the cost model says otherwise. ## Using both without paying for both twice The two are not rivals. They sit at different points: retrieval decides what is in front of the model, tuning decides what the model does with it. A support agent that answers from today's policy, in your exact ticket format, needs both, and the order of operations matters. Build retrieval first and measure it on its own. Score whether the right chunk was in the prompt, separately from whether the final answer was good. Teams that only score the final answer cannot tell a bad retriever from a bad prompt, and they end up tuning the model to paper over an index they never checked. Then write the prompt with examples and keep it in a file under review. Only when the examples stop paying for themselves does the tuning question become live, and by then you have something valuable for it: a set of real inputs with the outputs you approved, which is exactly the training file you need and the artifact nobody has on day one. One caution on the combination. Never train on examples whose answers came from the retrieved text, unless you keep the retrieved text in the training input too. Otherwise you are teaching the model to state facts it cannot see at run time, which produces a confident, fluent, wrong model, the most expensive kind. - Score retrieval alone: was the right passage in the prompt, yes or no. - Score the answer given a perfect passage. That splits retriever bugs from prompt bugs. - Keep the prompt in git with the eval set beside it. - Harvest approved outputs into the training file. That is your tuning dataset, earned rather than written. ## The third option nobody names: fix the context, not the model Between the two big methods there is a cheaper one that gets skipped because it has no vendor: change what goes into the window and how it is arranged. The glossary on this site has an entry for context engineering, and the short version is that the window is a budget and most teams spend it badly. Common wins, in the order they usually pay: cut the instructions that repeat, label each block of context so the model knows what it is reading, move the task to the end where the model attends to it, drop the tool definitions the task cannot use, and cache the stable prefix so you stop paying for it on every turn. Prompt caching in particular changes the cost arithmetic of long system prompts, and it is a config change rather than a project. The reason this works is unglamorous. A long prompt is not free attention. A fact can be in the window and still go unused, because it sits in an unlabelled wall of text a long way from the question, so an answer fails on layout rather than on retrieval. Rearranging a prompt is an afternoon. It should be the first thing tried and it is usually the last. ## Where Agentik sits on this question For the record, since this is our blog: Agentik {OS} does neither of these things to your model. We do not fine-tune and we do not run a vector database for you. The host you already pay, Claude, Claude Code, Cursor, ChatGPT, Codex, or Hermes, runs the model and pays the tokens. What we ship is the third option above, done for a line of work. The mechanism is context selection. One MCP tool, talk, takes a normal conversation turn and returns a compact pack of the agents and rules that turn needs, about 2 KB on Growth OS against about 110 KB for the full roster of 48 agents. The point is not the number. The point is that most of what an agent system needs is a decision about what to put in the window, which is the cheapest of the three interventions on this page and the one with no training bill. That is also the limit of it. If you need a small tuned classifier at high volume, or an index over ten years of your own documents with per-user permissions, that is a different job than the one we do, and you should build or buy it separately. ## What this guide does not settle The tests on this page tell you which failure you have. They do not tell you whether the result will be good enough, and no framework can. That number comes from an eval set of your own cases, scored by someone who knows what a right answer looks like in your business. If you do not have that set, build it before you pick a method, because without it both methods are guesses with different invoices. The second limit is that model behaviour moves. Advice about what needs tuning today can expire with one release, and I would not bet on any particular gap staying open. That biases this piece toward reversible fixes: prompts, retrieval, context layout. I am stating the bias rather than hiding it. The third limit is scope. This guide is about text models answering with facts and formats. If you are training on images, audio, or a task with no natural language target, the shape of the decision changes and the tests above do not transfer cleanly. Where I do not know, I would rather say so than write a rule that sounds complete. ## Symptom, likely cause, and the fix that matches it. Run ten real bad outputs through these rows before choosing a method. | Symptom you see | Likely cause | The fix that matches | What fine-tuning does here | | --- | --- | --- | --- | | Invents a product detail | Fact not in the prompt | Retrieval | Makes it more fluent, still wrong | | Quotes last year's policy | Ranker ignored version | Date filter before relevance | Nothing | | Right answer, JSON keys drift | No schema enforced | Structured output | Works, but a schema is cheaper | | Right answer, wrong voice | Behaviour underspecified | Examples in the prompt | Right tool once examples get long | | Skips a required step | Instruction buried mid-prompt | Move it to the end, label it | Works, at the cost of iteration speed | | Good but too slow | Prompt length, extra hops | Cache the prefix, cut context | Helps by shortening the prompt | | Good but too expensive | Large model on a narrow job | Small model tuned on approved outputs | This is the right case | | Right until a document changes | Knowledge baked into weights | Retrieval | Causes this failure | | Fine in tests, bad for one team | Permissions or index scope | Per-user filtering | Nothing | ## Sources - [Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks](https://arxiv.org/abs/2005.11401) - [Hu et al., LoRA: Low-Rank Adaptation of Large Language Models](https://arxiv.org/abs/2106.09685) - [OpenAI, fine-tuning guide](https://platform.openai.com/docs/guides/fine-tuning) - [Anthropic, Introducing Contextual Retrieval](https://www.anthropic.com/news/contextual-retrieval) - [Anthropic, prompt caching documentation](https://docs.claude.com/en/docs/build-with-claude/prompt-caching) ## FAQ ### Is RAG or fine-tuning better for teaching a model my company's data? Retrieval, in almost every case, because facts change and weights do not. Fine-tuning on documents teaches the model the sound of your data rather than a reliable memory of it. ### How do I know if I need fine-tuning? Run the examples test: if ten examples in the prompt get you most of the quality, keep prompting. If the gain only arrives past thirty examples and the prompt cost is now material, tuning is the cheaper path. ### Does fine-tuning make a model faster or cheaper? It can, by moving stable instructions out of the prompt and letting a smaller model do a narrow job. The saving only shows up at volume, and you should compute the break-even against your own bill. ### What does a fine-tune cost to maintain? A dataset you keep current, a retraining run every time the base model changes, and an eval set covering the behaviour you did not train on. Skipping the last one is how a tuned model quietly gets worse at old tasks. ### Can I use fine-tuning and retrieval together? Yes, and it is the normal shape for a support or research agent: retrieval for the facts, tuning for the format and voice. Keep the retrieved text in the training inputs, or you teach the model to assert facts it will not have at run time. ### What should I try before either one? Fix the context: cut repeated instructions, label each block, move the task to the end, drop unused tool definitions, and cache the stable prefix. It costs an afternoon and it resolves a surprising share of bad answers. # How to add an MCP server to Cursor URL: https://agentik-os.com/blog/how-to-add-an-mcp-server-to-cursor Published: 2026-09-19; updated: 2026-09-19 Cursor reads MCP servers from a file called mcp.json, in your home folder or in the project. This piece gives you the exact JSON for both kinds of server, the three places you check that it is live, and a table that maps every failure you will hit to its cause. ## Where Cursor keeps mcp.json There are two files, and they have the same shape. One is ~/.cursor/mcp.json in your home folder, and the server in it is there in every project you open. The other is .cursor/mcp.json in the root of a repo, and it is there only for that repo. Cursor's docs name both. The CLI reads the same two files in the same order: the project one first, then the home one, then any folder above you. Pick by blast radius, not by taste. A server that reads your own notes or your own mail belongs in the home file. A server that only means something inside one repo, like a local script that knows that repo's schema, belongs in the project file, where a teammate can see it in the diff and say no. The root key is mcpServers. Under it, each key is the name you will see in chat, and each value is one server. That is the whole file format. Everything else on this page is which fields go in that value. - Home file: ~/.cursor/mcp.json. Every project sees it. - Project file: .cursor/mcp.json at the repo root. Only that project sees it. - Same key in both: the project entry is the one that wins. - The file is plain JSON. A trailing comma is enough to make the whole file load as nothing. ## stdio or remote: which entry you are about to write Cursor lists three transports: stdio, SSE, and Streamable HTTP. In practice you are choosing between two worlds. A stdio server is a program on your own machine. Cursor starts it, talks to it down a pipe, and kills it when you quit. A remote server is a URL that someone else is running, and Cursor talks to it over HTTP. The MCP spec is short about what stdio means. The client starts the server as a subprocess. Both sides send JSON-RPC over stdin and stdout, one message per line, no newline inside a message. The server may write what it likes to stderr, and the client is told not to read stderr as a sign of failure. The rule that breaks the most home-made servers is the next one: the server must not write anything to stdout that is not a valid MCP message. One stray console.log in your own server, and the pipe is poisoned. The remote side is the newer Streamable HTTP transport, which replaced the old HTTP plus SSE pair. The server gives out one path that answers both POST and GET. The client has to send an Accept header that names both application/json and text/event-stream, because the server is free to answer a single request with either a plain JSON body or an SSE stream. You do not write any of that by hand. It matters only when you are reading a log and trying to work out which side hung up. So: a tool that has to touch your disk, your git history, or a local port is stdio. A tool that a team shares, that holds an account, and that you would rather not run on every laptop is a URL. Cursor's own table says the same thing in other words: stdio is single user and manual auth, the HTTP kinds are many users and OAuth. One more rule of thumb, for the cases where both would work. If you would be cross to find that tool on a colleague's laptop, it is a URL. If you would be cross to find your own files on a server, it is stdio. Most of the time you know which way you lean before you know why. Both choices cost you something and it is worth naming which cost you are taking on. A URL means you are trusting someone else's uptime, someone else's log, and a token that lives in a place you cannot grep. A local server means every laptop has its own copy, its own version, and its own way of being broken on a Tuesday. Pick the failure you would rather be the one to fix. ## Add a local stdio server, field by field Here is a whole ~/.cursor/mcp.json with one stdio server in it. Copy it, change the name and the args, save, and go back to Cursor. { "mcpServers": { "notes": { "type": "stdio", "command": "npx", "args": ["-y", "mcp-server-notes"], "env": { "NOTES_DIR": "${userHome}/notes" } } } } Five fields exist and only two are required. type is stdio. command is the program to run, and Cursor's docs are firm that it has to be on your path or written as a full path. args is an array of strings. env is a map of names to values for that one process. envFile is a path to a dotenv file, and it is the one field here that a remote server cannot use. Two things go wrong at this step, in our own experience of writing these entries, and both look like the server never existed. The first is command being a shell builtin or an alias. Cursor runs the command, not your shell, so source, a function from your zshrc, and a ~ that you meant the shell to expand will all fail. Write the full path. The second is a version manager. If npx or python only exists after nvm or pyenv has run, the app that Cursor launched from the Dock may not have it. /usr/bin/env in command does not save you either, because the PATH it reads is the one Cursor has, not the one your terminal has. You can dodge a typed-out path with the variables Cursor fills in for you. It reads them in command, args, env, url and headers. The set is ${env:NAME}, ${userHome}, ${workspaceFolder}, ${pathSeparator} and ${/}. Those last two exist so that one line can be right on a Mac and on Windows at the same time. Save the file and go back to the app. Cursor picks the change up on its own, and you do not have to quit and start again. If nothing at all shows up after a few seconds, that is your first real clue, and the next parts of this page are where you take it. ## Add a remote HTTP server A remote entry is smaller. There is no command to run, so there is a url and not much else. { "mcpServers": { "Agentik-OS": { "url": "https://mcp.agentik-os.com/api/mcp" } } } That is the entry we publish for Cursor, and it is the whole thing. No key, no header, no client id. The name is written Agentik-OS with that exact case for a dull reason worth knowing if you publish your own: Cursor title-cases a hyphenated slug in the UI, and our own agentik-core came back to us as Agentik Core. If you care how your server reads in the tool list, write the name the way you want to see it. Two optional fields matter. headers is a flat map, and it is where a bearer key goes if the server wants one. auth is for OAuth servers and takes CLIENT_ID, and then CLIENT_SECRET and scopes if they apply. You only need auth when the server hands you a fixed client id, which happens when the server does not do dynamic client registration or wants your redirect URL on a list first. If you leave scopes out, Cursor's docs say it will read scopes_supported from the server's auth metadata and use what it finds. Know that before you guess at a scope string, because a wrong one gives you a consent screen that grants you nothing and looks like it worked. Never paste a live key into a project mcp.json. Use ${env:MY_TOKEN} in headers and keep the value in your shell profile. envFile will not help you here, it is stdio only. - url: required. The one path that answers both POST and GET. - headers: optional. A flat map. Interpolation works here. - auth: optional. CLIENT_ID, plus CLIENT_SECRET and scopes when the server needs them. - envFile: not allowed on a remote server. Use ${env:NAME} instead. ## How to verify the server is actually connected Saving the file is not the check. There are three places to look, and they fail in different ways, which is exactly why you look at all three. Open Customize in the sidebar. Your server should be in the list with a toggle. If it is missing, Cursor never read the entry, and the fault is in the file, not in the server. If it is there but off, nothing will load and no error will be shown, because a server that is off is a server you asked for. That is the one state that never looks like a bug and is the first one to check. Then open the Output panel, which is Cmd+Shift+U, and pick MCP Logs from the dropdown. This is the only place that shows you what the server said while it was starting. Cursor's docs point at this panel for connection errors, auth problems and crashes, and it is where a bad command shows up as a spawn error instead of as silence. Third, in chat, look under Available Tools. A server that is up but has an empty tool list is a real state, and it is not the same bug as a server that is down. That case is almost always auth: you are talking to the server, the server knows who you are, and it has decided you get no tools. If you use the Cursor CLI, you get a faster loop. agent mcp list prints every server with its status, the file it came from, and its transport. agent mcp list-tools prints the tools and their inputs, which is the flat answer to whether the handshake worked. agent mcp login runs the sign-in on its own. The CLI reads the same mcp.json as the editor, so a fix in one is a fix in both. Do these in that order every time. It is quick and it tells you which of the three layers broke: the file, the process, or the account. Skip it and you can lose an hour to a bug that was a comma in a file you never opened. - Customize panel: is the server listed, and is the toggle on? - Output panel, MCP Logs: what did it say while it started? - Chat, Available Tools: did any tools arrive? - agent mcp list and agent mcp list-tools from a terminal. ## What the first tool call looks like Ask for the tool by name. If the server is called notes, ask the agent to use the notes server to find a file. Naming it takes the guessing out of the test. Cursor asks before it runs an MCP tool. You get a prompt with the tool name and an arrow that opens the arguments. Read the arguments the first time. This is the one moment where you get to see what a tool you did not write is about to do with the account you just gave it. That prompt is not a fixed law. MCP follows the same Run Modes as terminal commands, so in a mode like Auto-review an allowlisted tool runs at once and the rest goes through the classifier. The CLI has --approve-mcps to skip the prompts. Both are real choices with a real cost, and the cost is that you stop reading arguments. The response lands in chat as a block you can open, with the arguments and the result in it. A server can also send back an image as a base64 string, and Cursor puts it in the chat for a model that can read one. Make the first call a read. Ask it to list, to find, to show. Leave the writes for the second call, once you have seen what the first one did and how long it took. This is dull advice and it is the reason you will not have to explain a deleted row to anyone. ## Every failure, and what causes it The four symptoms you will run into are: the server is not in the list, the server is listed but no tools show up, sign-in loops forever, and calls time out. They have different causes and the fix for one will not touch the others. Before any of that, do the cheap test. Change one thing, then look. Two edits at once and you will not know which one did the work, and MCP gives you very little help in sorting it out after the fact. There is no undo and there is no stack trace, only a log with what the last run said. Server not listed is nearly always a parse failure. Cursor read the file, choked, and moved on. A comma after the last key, a smart quote from a blog post, or a // comment in a file that is plain JSON will all do it. Paste the file into any JSON parser before you blame anything else. Listed but no tools has two causes, and the logs tell them apart. If MCP Logs shows a spawn error, the command is wrong. If it shows a clean handshake and then a short tool list, you are looking at a server that answered. Ours answers a POST without a token with a 401 and a WWW-Authenticate header that says where to go, so a host that does OAuth turns that into a sign-in prompt and a host that does not just stays empty. The auth loop is the nastiest one because both sides look right. Cursor uses fixed redirect URLs for MCP OAuth: https://www.cursor.com/agents/mcp/oauth/callback for web and Agents, and http://localhost:8787/callback for the desktop app. If you are using static auth credentials against a server that only allows one redirect, sign-in from the desktop app will complete on the provider's side and come back to a URL the provider has never heard of. Register both. Timeouts split by transport. On stdio, the process died and its last words are on stderr, which the MCP spec lets a server write freely and lets the client ignore, so you will only see them in MCP Logs. On a remote server, a timeout usually means a slow tool, not a broken link, because the handshake happened and the tool list arrived before the call went out. One good thing: Cursor isolates a failing server. Its docs say an error shows in chat, that tool call is marked failed, and the other servers keep working. You can debug one entry without pulling the rest of the file out. ## The real cost is tool clutter, not setup Setup happens once. The thing you pay every day is that every tool on every enabled server is described to the model on every turn. Names, descriptions, and JSON schemas for arguments. Count them yourself: five servers with twenty tools each is a hundred tool definitions sitting in front of your actual question. You feel it as the model picking a worse tool, or ignoring a tool you know is there, or a context window that fills up faster than it used to. Cursor's own advice on the disable toggle names reducing tool clutter as a reason to use it, right next to troubleshooting. The fix is boring and it works. Keep the home file thin: the two or three servers you want everywhere. Put the rest in the project that needs them. Turn off what you are not using this week instead of deleting it, since the toggle keeps the config and drops the load. On teams, Cursor's enterprise allowlist can restrict which tools from an approved server may run automatically, which is the same idea with an admin behind it. This is the tradeoff of MCP as a whole, and it is worth saying plainly. Every server you add makes the agent more capable and every server you add makes it harder for the agent to choose. There is no setting that gives you both. - Home file: two or three servers, no more. - Project file: the ones that only make sense in that repo. - Toggle off in Customize instead of deleting. - Check MCP Logs after a server update. A new version can add fifteen tools you did not ask for. ## What the OAuth handshake is doing You do not need this to install a server. You need it the moment sign-in fails and you have to decide whose bug it is. The host POSTs to the MCP endpoint with no token. The server answers 401 and sets a WWW-Authenticate header that names a metadata URL. That header is the whole discovery step. Here is the exact one our endpoint returns, which you can pull yourself with curl and no account. WWW-Authenticate: Bearer realm="mcp", resource_metadata="https://mcp.agentik-os.com/.well-known/oauth-protected-resource", scope="mcp:tools", error="invalid_token" The host fetches that document, which is Protected Resource Metadata from RFC 9728. It learns which authorization server to go to. It fetches that server's metadata, registers itself or uses the client id you put in auth, and runs OAuth 2.1 authorization code with PKCE. You sign in, you press allow, and the host sends a bearer token on every later POST. Three failures live in that chain and the log line tells you which. A 404 on the well-known URL means the server never published discovery, and no host will finish. A redirect mismatch means the callback is not registered, which is the loop described above. A token that arrives and still gets refused means you are past auth and into permissions, which is a different team's problem. That last one is ours by design. An account with no plan can finish OAuth on our endpoint and still get an empty tool list, plus a JSON-RPC error saying a paid plan or an official OS unlock is required. Sign-in worked. Access did not. Any server with a paywall behind an open login will show you that shape, and reading it as an auth bug costs an afternoon. ## What adding an MCP server does not do It does not give the model judgement about when to use the thing. A tool description is a sentence. If two servers both expose something called search, the model will pick wrong some of the time, and no amount of config fixes that. It does not make the work safe. An MCP server runs code on your behalf against real accounts. Cursor's security page says the plain version: check the source, check what it can reach, use restricted keys, read the code for anything critical. Approval prompts help exactly as much as you actually read them. It does not give you memory. MCP moves tools and data in. It has no opinion about what should still be true tomorrow. If you want the agent to remember a constraint across sessions, something on the other side of the protocol has to hold it, and a tool list is not that thing. It does not survive an update on its own. Cursor's documented path for refreshing an npm-based server is to remove it in Customize, run npm cache clean --force, and add it back. A pinned version in args is the honest alternative: you choose when to move. ## What we publish for Cursor, and why it is one line Agentik {OS} installs on the host you already pay, and Cursor is one of six: Claude, Claude Code, Cursor, ChatGPT, Codex, Hermes. The Cursor entry is the remote JSON above, and the site also carries a cursor://anysphere.cursor-deeplink/mcp/install link that writes it for you. Or npx @agentikos/os install --host cursor from a terminal. Three routes, one file, same result. The reason there is no key in that entry is that auth is OAuth 2.1 with PKCE against https://mcp.agentik-os.com/api/mcp, and Cursor does that flow on its own. The host runs the model and pays for the tokens. We never buy tokens. On tool clutter we had to make a choice, and this is the one thing here that is a design decision rather than a fact about Cursor. An OS like Growth OS compiles 48 agents. Exposing them as tools would be a roster of about 110 KB in front of every turn. So there is one tool, talk, that takes a normal conversation turn and returns a compact pack of about 2 KB for the project you are in. Work that publishes, sends, spends or resets stops and waits for approve. The cost of that choice is real: you cannot see the whole roster in Cursor's tool list, because it is not there. /docs/mcp has the longer version. ## Cursor MCP failures, their cause, and the check that proves it | What you see | Most likely cause | Where to confirm | Fix | | --- | --- | --- | --- | | Server missing from Customize | mcp.json did not parse | Paste the file into a JSON parser | Remove the trailing comma, the comment, or the smart quote | | Listed, toggle off | Disabled, not broken | Customize panel | Turn the toggle on | | Listed, no tools in chat | Server started but returned none | MCP Logs: clean handshake, short list | Check auth and plan on the server side | | Spawn or ENOENT in MCP Logs | command not on Cursor's PATH | MCP Logs | Write the full path, or use ${env:NAME} | | Sign-in opens, never returns | Redirect URL not registered | Provider's OAuth app settings | Register both Cursor callbacks, web and localhost:8787 | | 401 on every call after sign-in | Token fine, permission refused | curl the endpoint and read the body | A plan or entitlement problem, not an auth one | | Tool call times out | stdio: process died. Remote: slow tool | MCP Logs for stderr, then the server's own logs | Fix the crash, or raise the tool's own timeout | | Tools appeared, then stopped | Server update changed the tool list | agent mcp list-tools | Pin the version in args | ## Sources - [Cursor docs: Model Context Protocol](https://cursor.com/docs/mcp) - [Cursor docs: MCP in the CLI](https://cursor.com/docs/cli/mcp) - [MCP specification: transports](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports) - [RFC 9728: OAuth 2.0 Protected Resource Metadata](https://datatracker.ietf.org/doc/html/rfc9728) - [RFC 7636: PKCE](https://datatracker.ietf.org/doc/html/rfc7636) ## FAQ ### Where is the Cursor mcp.json file? Either ~/.cursor/mcp.json in your home folder for every project, or .cursor/mcp.json at a repo root for that project only. Both use the same mcpServers root key. ### Why are my MCP tools not showing up in Cursor? Check the three places in order: is the server listed in Customize, is its toggle on, and what does MCP Logs in the Output panel say. A listed server with no tools is usually auth or permissions, not a broken config. ### Do I need a command or a URL? A command if the server is a program on your machine, with type set to stdio. A URL if it is a remote server someone runs for you, and then Cursor handles OAuth itself. ### How do I put an API key in mcp.json without committing it? Put the value in your shell environment and write ${env:MY_TOKEN} in headers or env. For stdio servers you can also point envFile at a dotenv file, but remote servers do not support that field. ### Why does sign-in keep looping? Cursor uses fixed OAuth redirect URLs, one for web and Agents and one at http://localhost:8787/callback for the desktop app. If the provider only has one of them registered, the callback lands nowhere and the flow restarts. ### How many MCP servers should I run at once? Fewer than you want to. Every enabled tool is described to the model on every turn, so keep the home file to two or three and push the rest into the projects that need them. # Measuring return on an AI system without fooling yourself URL: https://agentik-os.com/blog/measuring-return-on-an-ai-system-without-fooling-yourself Published: 2026-09-19; updated: 2026-09-19 Most AI ROI numbers are built on people guessing how long a task would have taken. That guess is made after the result is known, which is where the error lives. Here is how to set a baseline before the tool lands, what to log per task, why output counts and outcome counts split apart, and how to run a fair before and after when volume moves under you. ## Why the time saved number is usually made up Time saved is a gap between a number you saw and a number you imagined. You know how long the task took with the tool. The other half, how long it would have taken with no tool, never ran. People fill that half in after the fact, and they fill it in with a story about the work they just did well. There is a measured version of this. In a trial run by METR in early 2025, 16 skilled open source developers worked 246 real tasks from their own repos, with AI tools allowed on a random half of them. The tasks where AI was allowed took about 19 percent longer. The same people, right after the work, said AI had made them about 20 percent faster. Their read of what would have happened was off by some 40 points, in the way that felt good. That is one study on one group, and it does not mean your tool is slowing your team down. It means self report is not proof. If your case is a survey that asked people how many hours a week the tool saves them, times a loaded hourly rate, you do not have a number. You have a mood, scaled by payroll. The second break in that sum is the multiplier. Saved hours turn into money only if one of two things happens: you pay for fewer hours, or the free hours make something you can sell. Neither of them happens on its own. An hour saved in twelve places, in ten minute slices, is an hour nobody can spend. Say which of the two you expect before you start, because that choice sets what you have to count. - Never build a case on how much time do you think this saves you. - Write down which path you claim: fewer hours paid, or more sold. - If you can name neither, this is a skill test, not an ROI case. Say so. ## Set a baseline before the tool turns up The baseline is the whole ball game, and it is the step every team skips, because it is dull and it holds up the demo. Give it four weeks if you can, two at the least, and run it on the way you work now with nothing new in it. You are not grading your people. You are writing down what a normal month looks like, the bad weeks too, so that a later number has something to sit next to. Keep the spread, not just the mean. One mean handle time says almost nothing, since the tail is where the cost sits. Keep the median and the 90th, both. If the after picture moves the median and leaves the tail alone, the tool is helping with easy work, which may be just what you wanted, and is a very different claim from the team got faster. If the tool is already in, you can still get a baseline back, as long as you take it from systems that logged the work and not from people who recall it. Ticket times, commit and merge times, publish dates, CRM stage moves, call lengths, invoice dates. Pull the same window from last year as well as the months before the tool went in, since that gives you a shot at telling a real change from a seasonal one. Freeze the words on day one. What counts as one unit of work, what counts as done, which items are out, and who says so. Every rule you leave loose gets widened later, always the way that flatters the project. That is not spin. It is what people do when a number they care about sits near the line. - Four weeks of baseline, two at the least, on the process as it is. - Keep the median and the 90th, not the mean on its own. - Build it back from logs, never from memory, if you start late. - Fix the words for done and for out of scope before the tool lands. ## Pick one unit of work and define done A pilot you can measure has one unit. A ticket. A blog post. A pull request. A lead worked. A claim paid. Teams who try to measure a whole team end up with a board of numbers that all move for their own reasons, and no way to say which move came from the tool. Set done at the far end, past the point where the AI stops. A draft is not a post. A drafted reply is not a solved case. A patch is not merged code. Wherever the tool hands off, push your line one step past it, since that is where the work it made for the next person shows up. Write the out of scope rules now. Which items you skip, what you do with an item that starts before the tool and ends after, what you do with one that comes back, and whether a duplicate counts once or twice. Then hold to them. The way an honest team ends up with a false number is by dropping the awkward cases one at a time, each for a reason that seemed fair on the day. - One unit only: a ticket, a post, a pull request, a lead, a claim. - Done means shipped, sent, merged, paid, or closed and not back. - Set the line one step past the point where the tool stops. - Count what you drop, and keep that count next to the result. ## What to log, and where the data already sits You want one record per unit of work, written as it happens, not pieced together at the end of the quarter. Most of the fields are already in the tools you run. The new ones are the arm, how much a human had to edit, and the rework flag. Here is a record that has held up in real pilots, one JSON line per unit: { id, unit: ticket, arm: tool | control, opened_at, first_touch_at, done_at, handle_seconds, assisted: true, model_calls: 3, tokens_in: 8400, tokens_out: 1100, human_edit_ratio: 0.31, escalated: false, reopened_7d: false, reviewer, approved_at, outcome: resolved } Three of those do the heavy lifting. The arm lets you match like with like later on. The edit ratio, read as changed chars over final chars, is the cheapest proxy you have for how much of the job the tool really did. And the reopen flag is the one that kills a false win, since the fastest way to cut handle time is to close things that are not done. Log the bad path as hard as the good one. Count drafts thrown out, hand offs, retries, and items a person took over in full. A pilot that reports only the assisted items that shipped is reporting a filtered sample, and that filter is the very thing you set out to measure. If the tool wrote ten drafts and two were used, the cost per used draft is ten drafts, not two. - One event per unit, written as it happens, stored where you can query it. - Log the arm on every item, the control arm too. - Log calls and tokens, so cost per unit is a sum and not a guess. - Log the rework: cases that come back, hand offs, drafts you threw out. ## Output metrics and outcome metrics are not the same An output metric counts what came out of the machine. An outcome metric counts what the business got. Drafts written is output; posts that go live and get read is outcome. Replies drawn is output; cases closed that do not come back is outcome. Lines of code is output; a change that ships and stays up is outcome. Output moves first, and it moves more, since making the thing is the cheap half of the job. Pair every speed measure with a quality measure and read the two as one, or you will buy speed with defects and book it as a win. The DORA four keys are the clean worked case of that pairing: two flow measures, how often you deploy and how long a change takes, held next to two stability ones, how often a change fails and how fast you recover. The point is not the four names. The point is that a flow number read on its own can always be made to look better by lowering the bar. Pick your quality half from what already hurts when it goes wrong. Support: cases that come back inside seven days, and hand off rate. Content: how many drafts go live, and edits made after they go live. Sales: meetings held out of meetings booked, not mails sent. Code: how often a change fails. Each of those is already in your stack, which is why they outlive a pilot better than a survey nobody will run twice. This rule costs you time and you should know it. Outcome numbers are slow. A case comes back in a week, a post earns its traffic over a month, a merged change takes a quarter to prove it made no mess. Your pilot will end before those land. Report the output number with the date the outcome number is due, and hold the call open until then when the size of the spend is worth the wait. - Output is what came out: drafts, replies, calls logged, lines of code. - Outcome: posts read, cases shut for good, code that stays up. - Read a speed number next to a quality number, or do not read it. - Name the date the slow half of the number is due to land. ## Count the whole cost, not the licence The licence is the easy line and often the small one. Add the model spend, which on an agent that reads long files does not track seat count at all. Add the review time, which is new work you made, at the rate of the person who does it, and the reviewer is usually a senior one. Add the rework on bad output. Add the set up: the prompts, the wiring, the test suite, and the person who keeps them alive when a model shifts under them. Then add the cost of the counting, since it is not free and hiding it is how counting gets dropped in week three. Wiring up events, running a control arm, and writing the read out is real time from a real person. Put a number on it and ask if the spend earns it. A tool at a few hundred a month does not earn a four week trial with a control arm. A system that touches every customer does. Report net, per unit, with the sum on show. Cost per unit is total spend over the window, divided by units done in the window, where spend is licence plus tokens plus review time plus rework time. Anyone who wants to fight your call can then fight a line, which is the point. A single ROI percent with no division on show cannot be argued with, and numbers you cannot argue with do not last five minutes in a finance room. - Licence and seats, plus model spend, read per unit where you can. - Review time at the rate of the person who does the review. - Rework: hand offs, cases that come back, drafts you threw out. - Upkeep: prompts, wiring, tests, and the person who owns them. - The counting itself, in hours, named as a cost line. ## How to run a fair before and after when volume changes Volume will move during your pilot. A release lands, a campaign runs, a rival goes down, a holiday empties the queue. Totals go dead the moment that happens, since total hours rise with volume whatever the tool does. Switch to rates: minutes per unit, cost per unit, cases back per hundred, units per person per week. A rate lives through a volume change. A total does not. Rates on their own still leave you open, since the mix can move too. Easy tickets arriving in bulk will cut your handle time with no help from any tool. So hold something back. In order of strength: split by coin flip at the item level, which is what METR did and which beats all the rest; split by team or by queue; stage the roll out so week one is one group and week three is the next; or keep one queue on the old way for the whole run. A hold out of 20 to 30 percent is enough to catch a big effect and cheap enough to live through the meeting. With a hold out, weigh the change in the treated group against the change in the control group over the same weeks, rather than before against after in the treated group alone. That subtraction is what takes out the release, the season, and the new hire, since those hit both groups. In public policy this is called difference in differences, and the Magenta Book sets out when it holds, which is worth a read before you claim it. Two guard rails. Fix the window and the sums before you look at the data, since a window picked after the fact is a result picked after the fact. And keep away from the fan arm: if the pilot group put their hands up and the control group did not, you are measuring keenness. Assign the arms. Do not let them form. - Use a rate per unit, not a total, the moment volume moves. - Hold out 20 to 30 percent of items or people for the whole run. - Weigh the change in one arm against the change in the other. - Fix the window and the sums before you look at the numbers. ## A worked example, with numbers that are made up Every number below is ILLUSTRATIVE. They are invented to show the sums and the traps. They are not results we measured, not a customer case, and not a claim about what any tool does. Copy the method, not the figures. Set up for the example. A support team of four. The unit is one ticket. Done means solved and not back inside seven days. The baseline is four weeks with no tool. Then four weeks with a drafting aid given to three of the four, with the fourth held out on the same kinds of queue. Baseline, illustrative: 1,200 tickets, median handle time 14.0 minutes, 11 percent of them come back, and one that comes back costs about 9 more minutes. So the real minutes per ticket is 14.0 plus 0.11 times 9, which is 14.99. Pilot, illustrative: volume rose to 1,500 tickets because a release shipped. Total team hours went up, so the naive read is that the tool made things worse. Per ticket, the treated group shows a median handle time of 11.2 minutes and 13 percent coming back. Real minutes is 11.2 plus 0.13 times 9, which is 12.37. That is 2.62 minutes better per ticket, or 17.5 percent, and you can only see it because you moved to a rate. Now the hold out, which is the part that decides whether you learned a thing. Say the held out person, illustrative again, also got better, from 14.99 to 13.60 real minutes, because the release made the tickets easier. The change in the treated group is minus 2.62. The change in the control group is minus 1.39. The gap is minus 1.23 minutes per ticket, and that gap is your estimate of what the tool did. With no hold out you would have claimed 2.62 and been wrong by more than double. Money, illustrative. 1,500 tickets times 1.23 minutes is 1,845 minutes, near enough 30.8 hours over four weeks. Against that: $260 of licence and tokens, plus 6 hours of a lead keeping prompts and wiring alive, plus review time that already sits inside the handle time. So the honest claim is that the team took on 300 more tickets with no fifth hire, and gave back about 25 hours net. The dishonest read of the same data is a 17.5 percent lift and 65 hours saved, and it comes out of the same sheet. What the example would not prove, even if the numbers were real. One team, one month, one queue. The share of tickets coming back went the wrong way by two points, which is a quality signal you would want to watch for another month before you scale. And one person as a control arm is a tiny sample, so the honest write up says the effect looks positive, looks small, and here is the date we check it again. ## How AI ROI numbers go wrong The table below lists the ways a pilot ends up with a confident wrong number. Most of them are not fraud. They are the ordinary result of counting something you want to be true, on a deadline, with data that was never collected for the job. Two of them carry extra weight because they are near universal. Counting output and calling it outcome, which lifts every early pilot. And picking the window after you see the data, which can make any result you like out of an honest set of numbers. Guard against both in writing, before the tool is switched on. ## Write the decision rule before the pilot starts Decide up front what result makes you keep this, what result makes you kill it, and what result means you do not know. One page, signed by whoever owns the budget, before anyone touches the tool. It takes twenty minutes and it is the only real guard against the ending where the pilot runs for ever because every number can be read two ways. Make the rule a rate and a threshold, not a direction. Not handle time gets better, which noise alone will satisfy. More like: real minutes per ticket, read as the gap between the arms, improves by at least 8 percent, with the share of tickets coming back no more than one point above baseline, over four weeks. Add the not sure branch: if the gap is positive but under the bar, we run four more weeks once, then stop. Then say who reads the result and when. A number with no meeting on it is a number that gets lost, and the tool stays either way, which is the ending the whole job was meant to head off. Put the review date in the calendar on the day the baseline starts. - Name the metric, the bar, and the window, up front. - Include a stopping rule for the case where you cannot tell. - Name the person who decides, and the date they decide on. ## What Agentik can and cannot tell you here We sell AI operating systems that install on the MCP host you already pay for, so two of these lines work out a bit differently for us, and you should know which. The model runs on your host and your host pays the tokens, so the model spend in your cost per unit is a bill you already get and can read, not a line we invoice. Work that publishes, sends, spends, or resets waits for a human approval, so the approval is a real event with a real time stamp, and you can read review time off it instead of guessing at it. What we cannot do is tell you whether the work got better. We do not sit in your CRM, your CMS, or your support desk, so the outcome half of every metric on this page comes out of your systems, not ours. Any vendor who hands you an ROI dashboard for their own product is showing you their output counts with a currency sign in front. The baseline, the hold out, and the outcome number are yours to build, and they are the one part of this that no vendor can hand you. ## What this method does not measure, and when it is too much Small teams cannot get the numbers to speak, and no amount of care fixes that. With four people and 200 items you will not reliably see a 10 percent effect, and a clean looking result at that size is as likely to be noise as signal. The right move is not to fake a decimal place. It is to say what size of effect you could have seen at all, report the direction, and treat the call as a judgement helped by numbers rather than one settled by them. The method also misses all that is not the unit you picked. The learning curve, which means an early read sells short a tool people are still getting used to, and a late read may oversell it once the easy wins are taken. Morale, which is real and moves both ways. Option value, which is the work that becomes possible rather than faster, and which no before and after can see, since the before holds none of it. If the case for a tool is that it lets you do a thing you were not doing at all, count take up and quality of the new thing, and drop the ROI frame. And the method costs more than some calls are worth. A four week baseline, a hold out arm, events logged per task, and a write up is perhaps a week of one person, spread over two months. Do not spend that to judge a tool that costs less than the counting. For small buys, run it a month, ask the people using it if they would fight to keep it, and move on. Save all this for the systems that touch every customer, every invoice, or all that you publish. - Under a few hundred items, give a direction and a doubt, not a percent. - Read it twice: once at week four, once at week twelve. The curve moves. - If the tool adds new work rather than faster work, count take up instead. - Never spend more on the counting than the call is worth. ## Ways an AI ROI number goes wrong, and what to do instead | Failure mode | What it looks like | Why it happens | Fix | | --- | --- | --- | --- | | Survey ROI | Hours saved per week times a loaded rate | The half that never ran is imagined after the result is known | Measure the task, keep a control arm, drop the survey | | Totals under moving volume | Total hours rose, so the tool failed | Volume changed for reasons unrelated to the tool | Report rates per unit: minutes, cost, cases back per hundred | | No baseline | We think it used to take about a day | Nobody wrote down the old process before roll out | Rebuild from system timestamps, never from memory | | Output counted as outcome | 1,400 drafts generated this month | Making the thing is the cheap half and moves first | Count published, resolved, merged, or paid | | Rework invisible | Handle time down 20 percent | Items closed early come back a week later | Track cases that return, hand offs, and discarded drafts | | Review time unpriced | Only the licence appears in the cost line | The new review work lands on a senior person | Add reviewer minutes per item at their rate | | Window chosen after the fact | Compared against the worst month of last year | The window was picked once the data was visible | Fix the window and the sums before looking | | Enthusiast arm | The pilot team loved it and got faster | Volunteers differ from the people who did not volunteer | Assign arms by queue or by coin flip, do not let them form | | Stopping on a good week | Declared a win at week two | Early noise is large and flattering | Set the window up front and run it out | ## Sources - [METR, randomized controlled trial of AI tools on experienced open source developers](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) - [DORA, the four keys: flow measures paired with stability measures](https://dora.dev/guides/dora-metrics-four-keys/) - [HM Treasury Magenta Book, guidance on evaluation design and comparison groups](https://www.gov.uk/government/publications/the-magenta-book) - [NIST AI Risk Management Framework 1.0, the Measure function](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf) ## FAQ ### How do I measure AI ROI if I never took a baseline? Rebuild one from systems that logged the work: ticket timestamps, merge times, publish dates, CRM stage changes. Pull the same window from last year too, so a seasonal swing does not get credited to the tool. ### Is time saved ever a valid metric? Yes, when it is measured per task against a control arm rather than estimated by the person who did the work. Saved time turns into money only if you pay for fewer hours or sell more output, so name which one you claim. ### How long should an AI pilot run? Four weeks of baseline and four to eight weeks of pilot covers most operational work, because rework and returned cases need a week or two to show up. Anything shorter mostly measures novelty and the learning curve. ### What size hold out do I need? Twenty to thirty percent of items or people, held out for the whole run, is usually enough to catch a large effect. Splitting item by item beats splitting by team, and both beat comparing before against after. ### Should I count tokens in the cost of a unit of work? Yes, and log calls and tokens per item so the division is a sum rather than an allocation argument. Model spend stops tracking seat count as soon as agents start reading long documents. ### What if the tool enables work we were not doing at all? Then a before and after cannot see it, because the before holds none of that work. Count take up, quality, and whether the new output gets used, and drop the ROI frame until there is a baseline to compare against. # What to ask an AI vendor before you sign URL: https://agentik-os.com/blog/what-to-ask-an-ai-vendor-before-you-sign Published: 2026-09-19; updated: 2026-09-19 Eight questions decide whether an AI deal is safe to sign: who pays for inference, where your data goes, what you keep on exit, what the model is, what the system does alone, what the log holds, what broke last year, and how the deal ends. This is what a good answer sounds like, what a dodge sounds like, and the follow-up that ends it. ## How to run the call so the answers are checkable Ask for the artifact, not the answer. Every one of these questions is settled by a document the vendor already has: the order form, the data processing terms, the sub-processor list, the status page, the export docs, one line of the audit log. A rep who knows the product names the document and the clause. A rep who does not know says a nice thing about trust. So the shape of the reply matters more than the tone. Score each answer with three marks. Two points when the reply names a file, a number, a switch in the product, or a clause. One point when it states a true principle with no artifact behind it. Zero when it answers a question you did not ask. A zero on data or on unattended action is a stop, not a haggle. Ask each question twice, once to sales and once in the tech call, and write both replies down. When the two do not match, you have found the soft spot, and you can ask which one goes in the contract. Then put the good answers in the order form. If it is not in the deal, it is a hope. A hope does not renew, does not pay a credit, and does not survive the rep who leaves in March. - Bring the eight questions on one page and read them out in order. - Ask for a file after every answer: DPA, sub-processor list, log sample, export. - Record who said what, so a later claim has a date on it. - Move the two or three answers you care about into the order form as text. ## Who pays for inference, and what happens at ten times the volume There are three shapes, and they price risk in three ways. The vendor buys the tokens and sells you a seat, which is easy to budget and hides the unit cost. You bring your own key, which shows you the real number and hands you the rate limits. Or the model runs on a host you already pay, so nobody resells you tokens at all. None of these is the right one. But the vendor must be able to say which one you are buying. The question that finds the edge is not the price. It is the cap. Ask what the plan includes per month, whether the cap is per seat or per account, what happens when you hit it, and what the overage costs per unit. Then ask the four questions that decide the real bill: do tool calls count, do retries count, do failed calls count, and does a long document count once or once per turn. An agent that reads a 200 page PDF on every turn is not priced like a chat box. A good answer is boring and numeric. A bad answer is the word unlimited with fair use next to it, which means there is a cap and they do not want to name it. Ask to see the metering screen in a live account, and ask for last month's usage as a CSV. If the product cannot show you what it spent, it also cannot show you what it spent on the day it went wrong. The tradeoff to accept: a seat price protects you from a spike and costs you the ability to shop for a cheaper model later. Your own key does the reverse. Pick the one that matches who eats a surprise in your company, and say so out loud at the table. - Ask: what is in the plan per month, per seat or per account? - Ask: what is the overage rate, and is the cap hard or soft? - Ask: do retries, tool calls, and failed calls draw down the same pool? - Ask: if your model provider raises price mid term, who absorbs it? ## Where does your data go after you press send The honest answer is a path, not a promise. Your text leaves the browser, lands in the vendor app, and is then sent to one or more model providers, plus a search tool, plus a log store, plus whatever watches for abuse. Each hop is a company with a name and a country. Ask for the sub-processor list, and ask which of those names sees the prompt text and which sees only metadata. The list exists. In the EU it has to, because a processor has to name who it hands the data to under Article 28 of the GDPR. Then ask about the three things people mix up. Retention is how long a copy sits on disk. Training is whether your text shapes a future model. Human review is whether a person can open it. A vendor can say we do not train on your data and still keep prompts for 30 days and still let a support engineer read one. All three can be fine. You just need to know which ones are on. A good answer names the model provider, gives the retention window in days, says where the zero retention switch lives, and admits the exception. There is almost always an exception, often an abuse review copy kept for a short window. A vendor who says there is no copy anywhere has not read their own provider terms. An evasive answer swaps in a badge: we are SOC 2 Type II. That is an audit of controls the vendor picked, on a scope the vendor defined. It is worth having, and it is not a map of where your text went. - Ask for the sub-processor list with company names and regions. - Ask: is prompt text retained, for how long, and where do I turn that off? - Ask: can staff open my workspace, under what ticket, and do I get told? - Ask for the SOC 2 scope page, not the badge, and read which systems it covers. ## What happens to your data on the way out Test the export during the trial, not during the divorce. Ask for a full export today, download it, and open the file. You are checking three things: is it self serve or a support ticket, does it hold the inputs as well as the outputs, and is it a format you can read without their app. A ZIP of JSON with the original files is good. A PDF report is a souvenir. The part people forget is the memory. The reason an AI system gets useful in month six is the context it built up: notes, labels, past answers, a store of your documents. Ask whether that store is in the export. Vector indexes usually are not, and usually should not be, because the numbers are tied to one model and are worth nothing to the next vendor. What you need is the source text and the labels you added, so the next system can build its own index. Then ask about deletion, which is the mirror image. How long after termination can you still pull an export, how long until live data is gone, and how long until it leaves the backups. Backups roll on their own clock, often a month or so behind live. A vendor who says deletion is instant everywhere is describing a system with no backups, which is a different problem. A good answer sounds like this: export from settings at any time, JSON plus the original files, read only access for 30 days after the term ends, live data purged in 7 days, backups aged out within 35, and a written deletion note on request. An evasive answer is we will work with you at that time. That sentence costs nothing to say and binds nobody. - Ask: can I run a full export myself right now, with no ticket? - Ask: does the export hold my uploads, my edits, and the model output? - Ask: how many days of read only access do I get after the term ends? - Ask: when does it leave the backups, and will you put that in writing? ## What happens when they swap the model underneath you Ask which model and which version runs each feature today. Write the answer down. This is the single fastest way to tell a product team from a wrapper: a product team knows that summarize runs one model and classify runs a cheaper one, and can say so in a sentence. A wrapper says we use the best model for the job, which is true of everyone and tells you nothing about what changes next Tuesday. The change will happen anyway. Providers retire versions, and a vendor who promises to pin your model forever is promising something they do not control. So do not ask for a freeze. Ask for notice, a window, and a way to see what served you. A fair answer is: model changes go in the changelog with notice before the switch, and the old version stays available for one release while you re-run your own checks. Then ask whether routing is fixed per feature or picked per request. Per request routing is a real design, and it means your outputs can differ between two identical calls for reasons that have nothing to do with you. If they route, ask whether the log records which model served a given request. Without that line you cannot debug a bad answer, and you cannot tell a regression from a bad day. The follow-up that ends the dodge: ask for the last three model changes and what they told customers each time. A vendor with a changelog will send a link in a minute. A vendor with no history of telling anyone will explain why this is hard. - Ask: which model and version serves each feature today? - Ask: is routing fixed per feature, or chosen per request? - Ask: how much notice before a change, and can I stay one version back? - Ask: does the log name the model that served a given call? ## What the system does when nobody is watching Make them list the actions. Not capabilities, actions: send an email, post to a public account, write a field on a customer record, delete a row, charge a card, open a ticket, run code, call an API you own. Then ask which of those the system can do with no person in the loop, and which one has the worst blast radius. The answer to that second question is the one you design the deal around. Ask where the gate is enforced. A gate written into a prompt is a request. A gate enforced by the server, which refuses the call until an approval record exists, is a control. The difference matters because instructions can arrive from the data: a web page, a PDF, an email in the inbox the agent reads. If a document can talk the model into skipping the confirmation, the confirmation was never a gate. Ask what layer stops it and how they tested that. Then ask about retries, which is where the quiet damage lives. A send that half fails and is retried can send twice. Ask whether actions carry an idempotency key, and what happens if the worker dies after the send and before the write. A team that has run this in production answers fast, because they have seen the double send. A team that has not will tell you it is very unlikely. A good answer is a short list plus a sentence like: these four actions are gated, the gate is server side, and here is the log line from a blocked attempt. An evasive answer is it always asks you first, said in the tone of an obvious thing. Ask to see the ask, then ask what happens when someone clicks approve on fifty items at once. - Ask for the full list of side effects, named one by one. - Ask: which of those run unattended, and what is the largest one? - Ask: is approval enforced server side or in the prompt? - Ask: what stops a retry from sending twice? ## What is actually in the audit log Full audit logging is a feature name, not an answer. Ask for one record, redacted, as raw JSON. Then read it against what you would need in a real dispute: who acted, when, which agent or feature, the input, the output, the model and version, the tool that was called and the arguments it was called with, and the approval with the name of the person who gave it. Many products log that an event happened and not what it said. The content is the part you need when a customer forwards an email and asks who wrote this. Ask who can delete a record. If an admin can, the log is an operations tool, not evidence. Ask whether records can be streamed out to your own store, because a log you can only read inside the vendor app is a log you lose on the day the account is suspended. An export endpoint or a drain into your own system is the difference between your record and their record. The tradeoff is real and you have to pick a side. Logging the content makes disputes answerable, and it turns the log into a second pile of personal data with its own retention clock, its own access list, and its own deletion duty. Logging metadata only keeps the pile small and leaves you blind. Most teams want content logged, kept for a defined window, access limited, and deleted on a schedule. Write the window into the contract, because the default is usually whatever the vendor's disk allows. - Ask for one log line as JSON before you sign, not a screenshot. - Ask: is the prompt and the output in the record, or just the event? - Ask: can an admin edit or delete records, and is that itself logged? - Ask: how do I get the log into my own store, and how long is it kept? ## Uptime numbers, incident history, and the gap between them Do not ask for an uptime number. Everyone has the same one. Ask for the status page with a year of history and the postmortems, then read what they wrote on a bad day. That page tells you how the team behaves under load, which is the thing you are buying. A status page with no entries is not a clean record. It is a page nobody updates. Then read the definition of downtime in the agreement, because that is where the number is made. Ask whether slow counts, and at what latency. Ask whether an outage at the model provider counts as their outage. Many AI agreements carve out third party providers, which is understandable and also means the availability you are promised is not the availability you will get. If the carve out is there, ask them to state the end to end number they actually observe and where you can see it. Ask how a credit works. Is it automatic, or do you have to claim it in writing within a window. What share of the monthly fee is at risk. Credits are small by design and they are not a remedy for a bad week. Their value is as a signal: a vendor who pays automatically has told you they expect to be judged on it. The follow-up: name the last three incidents, tell me the cause, and tell me what changed afterwards. A team that runs reviews answers with specifics. A team that does not will describe the last incident as an isolated issue with an upstream provider, which is the sentence you will hear again in six months. - Ask for the public status page URL and read a year of it. - Ask: what counts as downtime, and does slow count? - Ask: is a model provider outage excluded from the SLA? - Ask: is the credit automatic, and what share of the fee is at risk? ## How the contract ends, and what ending it costs Find the auto renewal date and the notice window before you find the price. A 12 month term with a 60 day notice window means the day you can cancel is ten months away, and most teams discover this in month eleven. Ask for the exact date in the order form, in numbers, and put a reminder in a calendar the day you sign. That is a two minute task that has saved more money than most negotiations. Then ask the questions about the end that nobody volunteers. Is there a cap on the renewal increase, in a percent, written down. Can you leave for convenience, or only for cause. What survives termination: confidentiality, deletion duties, the export window. What happens to a one time or lifetime license if the product is retired. And what happens on an acquisition, since assignment clauses usually let the deal move to a new owner whose plans you have never seen. A good answer to the sunset question is a clause, not a feeling. Source code escrow sounds like the answer and rarely is, because you will not run their stack. A better answer is a defined notice period, an export that already works, and a data term that keeps running after the product stops. Ask what happened the last time they sunset a feature and what customers got. An evasive answer here is a compliment: our customers do not leave. Ask again, as a mechanics question. If we send notice on the first of a month, what do we get, in what order, and on what dates. A vendor who has done this calmly walks you through it. A vendor who has not will change the subject to the roadmap. - Ask: what is the exact auto renew date, and how many days notice? - Ask: is the renewal increase capped, and where is that written? - Ask: can I terminate for convenience, and what is owed if I do? - Ask: on acquisition or sunset, what do I keep and for how long? ## Score the answers, not the vendor The table below is the sheet we use. One row per question, with the shape of a good answer, the shape of a dodge, and the follow-up that closes the gap. Read the middle column before the call. Once you have heard we take security very seriously in answer to a question about retention, you will hear it everywhere, and you will stop losing the thread. Two rows are pass or fail rather than scored. Where the data goes, and what the system does unattended. A vague answer on either one is not a negotiating position, because both are things the vendor either knows or has not built. Everything else can be fixed with a clause: a cap, a notice period, an export window, a log retention term. One more move at the end of the call. Ask what they would want to know if they were buying this. Good teams answer with something uncomfortable and specific, like watch our latency on long documents, or our connector for that CRM is two months old. That answer is worth more than the whole sheet, because it tells you they know where the product is thin. ## Where Agentik sits on this sheet We sell official AI operating systems that install on the MCP host you already pay for: Claude, Claude Code, Cursor, ChatGPT, Codex, Hermes. That answers the first question in a way that removes it. The host runs the model and pays the tokens, so there is no token pool to negotiate with us and no overage rate to cap. It answers the fifth one too: work that publishes, sends, spends, or resets waits for a human approval, through an approve step. Pricing is $19.99 once for one OS, or $19 a month for three, $99 for ten, $199 for unlimited. It does not answer the third question for you, and we should be plain about that. Because the model runs on your host, the retention and training terms that apply to your prompts are your host's terms, not ours. That is better for some buyers and worse for others. If you need one contract that covers the model as well as the app, an architecture like ours moves that question to a second vendor rather than closing it. Ask us the same eight questions, and hold the answers to the same three marks. ## Where this checklist does not help This is paper. A vendor can answer all eight questions well and still ship something your team quietly stops using in week three. Nothing on this sheet tests whether the output is good, whether the product fits how your people work, or whether the thing it does best is the thing you need. Run a real pilot on real work for that, with the people who will use it, and let them say no. The cost is the other limit. Doing this properly takes two calls, a document review, and someone with the standing to ask a legal question. That is a few hours of senior time. Spending it on a $19 a month tool that touches no customer data is bad judgment. For a tool at that size, three checks are enough: run the export, read the retention line, and confirm nothing sends without a click. Save the full sheet for anything that touches customer records, money, or your public voice. The last limit is about young vendors. A small team will fail some of these for honest reasons: no SOC 2 yet, no published status page, no formal notice policy. That is not the same as a dodge. We do not have that yet, here is what we do instead, and here is when we will is a better answer than a polished sentence with nothing in it. Grade on the shape of the answer, and keep the pass or fail rows where they are. ## Eight questions, with the shape of a good answer, a dodge, and the follow-up | Question | Good answer sounds like | Evasive answer sounds like | Ask next | | --- | --- | --- | --- | | Who pays for inference? | “Your plan holds N units a month per account, overage is $X per unit, retries count once.” | “Unlimited, subject to fair use.” | “Show me the metering screen and export last month as CSV.” | | Where does my data go? | “Here is the sub-processor list. Prompts are kept 30 days. Zero retention is a switch in settings.” | “We are SOC 2 Type II and take security seriously.” | “Which sub-processor sees prompt text, and what is the SOC 2 scope?” | | What do I keep on exit? | “Self serve JSON export plus original files, read only for 30 days, backups aged out in 35.” | “We will work with you at that time.” | “Run the export now, during the trial, and send me the file.” | | Which model is behind this? | “Feature A runs version X, changes go in the changelog with notice, prior version stays one release.” | “We always use the best model for the job.” | “Is routing per feature or per request, and does the log name the model?” | | What runs without a human? | “These four actions are gated server side. Here is a log line from a blocked attempt.” | “It always asks for confirmation first.” | “If a document tells the model to skip the gate, what layer stops it?” | | What is in the audit log? | “One record holds actor, time, agent, input, output, model, tool arguments, approver.” | “We have full audit logging.” | “Send one redacted record as JSON, and tell me who can delete it.” | | What broke last year? | “Here is the status page and three postmortems, with what changed after each.” | “We target 99.9% uptime.” | “Does a model provider outage count against the SLA, and is the credit automatic?” | | How does the deal end? | “12 months, renews on this date, 30 days notice, increase capped, export runs after the term.” | “Nobody churns, so it rarely comes up.” | “Write the renewal date and the notice window into the order form.” | ## Sources - [GDPR, Regulation (EU) 2016/679, Article 28 on processors and sub-processors](https://eur-lex.europa.eu/eli/reg/2016/679/oj) - [EU AI Act, Regulation (EU) 2024/1689, transparency and record keeping duties](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) - [NIST AI Risk Management Framework 1.0 (NIST AI 100-1)](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf) - [AICPA, SOC suite of services, on what a SOC report covers](https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services) - [Model Context Protocol specification, including the authorization model](https://modelcontextprotocol.io/specification/2025-06-18) ## FAQ ### What is the single most important question to ask an AI vendor? What can the system do without a person in the loop, and where is that gate enforced. Every other risk on the list is recoverable, and an unattended action that reaches a customer is not. ### Is SOC 2 enough to answer the data question? No. A SOC 2 report describes controls the vendor chose over a scope the vendor defined, so read the scope section and still ask for the sub-processor list and the retention window. ### Should I demand that the vendor pin the model version? No, because providers retire versions and the vendor cannot hold that promise. Ask for notice before a change, one release of overlap, and a log that records which model served each call. ### How much diligence does a $19 a month tool deserve? Three checks: run the export yourself, read the retention line, and confirm nothing sends without a click. Save the full sheet for anything touching customer records, money, or your public voice. ### What if the vendor is too small to answer half of these? Grade the shape of the answer, not the size of the company. A clear we do not have that yet, plus what they do instead, beats a confident sentence with no document behind it. ### Do these questions change if the model runs on my own host? Two of them move rather than disappear. Inference cost becomes your bill to watch, and retention and training terms become your host's terms, so ask the same questions of that provider. # What is an AI operating system? URL: https://agentik-os.com/blog/what-is-an-ai-operating-system Published: 2026-09-12; updated: 2026-09-18 An AI operating system is a set of specialized agents, shared memory, and skills that runs inside the host you already pay. Agentik never buys your tokens. ## It is not software you install next to the work A chatbot answers. An automation fires when a trigger matches. An AI operating system holds a line of work: who speaks, what they may touch, and what has to stay true after they finish. The model still thinks on the host. The OS decides the order. That is why “AI operating system” in a search result is often a PC, a voice runtime, or a generic agent builder. Those products install something new. Agentik does not. You bring Cursor, Claude, ChatGPT, Codex, or Hermes. The operative system arrives over MCP. ## An AI operating system for companies is a department, not a prompt A pile of AI agents is not a department. A company operating system names the jobs, the handoff, and the thing that is not allowed to change. Content OS writes. Growth OS looks for the gap. Librarian OS keeps the record. Each one is an operative system, not a skill pack. For a small business the same rule holds, only the roster is shorter. Official public OS today are Content, Growth, and Librarian. Decision is retired. You do not need a new vendor for every task if the host you already pay can run the line. ## Agentic OS, in one sentence Agentic OS is the same idea under a newer name: agents that act, inside a system that remembers the constraint. The word is easy to confuse with Agentik. Agentik is the product. An agentic operating system is the category. Models think. Agents act. The OS keeps the line. If a page cannot say that in two sentences, it is selling a chatbot with extra steps. ## What is an agentic operating system? An agentic operating system is an AI operating system whose agents are allowed to act, and whose memory keeps the constraint after they act. The category name is agentic OS. The product name is Agentik. For a company, an agentic operating system for the enterprise is one line of work with a named owner, a shared memory, and a gate. It is not a personal assistant, and it is not a PC operating system you download. ## AI operating system examples you can install The public examples are the official OS. Content OS holds the editorial line. Growth OS holds audience, offer, and the next experiment: the go-to-market work, not a new marketing app. Librarian OS holds the record. Decision is retired. Each one installs in Claude, Claude Code, Cursor, ChatGPT, Codex, or Hermes through the Model Context Protocol. A GitHub template is a folder. If the example cannot name who approves, it is a demo. ## AI OS against the things people confuse it with | | Chatbot | n8n-style automation | Agent platform | AI operating system | | --- | --- | --- | --- | --- | | Where it runs | A chat window | A workflow host | A new app | The host you already pay | | What it holds | The last reply | A trigger | A canvas of agents | Memory, skills, and the line | | Who pays the model | You, or the vendor | You | Often the vendor | You. Agentik never buys tokens | | What ships | An answer | A job | A builder | A specialized OS | ## FAQ ### What is an AI operating system? Specialized agents, memory, and skills that run on the host you already pay. It is not a chatbot and not a second app you install beside your tools. ### Is an AI operating system for companies different from a personal assistant? Yes. A company OS names the jobs, the handoff, and the constraint. A personal assistant answers one person. ### What is an agentic OS? Agents that act, inside a system that remembers the constraint. Agentik is one product in that category. It runs on the host you already pay. ### What are examples of an AI operating system for a company? Content OS, Growth OS, and Librarian OS. They are specialized lines, not one chatbot. Decision is retired. ### How is an AI operating system different from ChatGPT? ChatGPT is a host. An AI operating system is the line of work you install on that host: agents, memory, and a human gate. The host still runs the model. ### Do you need to code to install one? No. You add the remote MCP server in the host you already pay. A custom OS, when the catalog does not fit, is on demand, and we do not publish a build time. ### Can an agentic OS replace employees? No. It drafts and proposes. A named person still approves the send, the publish, and the write to a customer record. ### Does Agentik buy the model tokens? No. The host runs the LLM. Agentik never buys your tokens. # AI operating system template for Claude: build, or install URL: https://agentik-os.com/blog/ai-operating-system-template-for-claude Published: 2026-09-13; updated: 2026-09-18 An AI operating system template for Claude is a repository you assemble. An installed OS is the same idea, already named, already constrained, delivered to the host you pay. ## What a template actually gives you Public templates (AIS-OS and the various ai-operating-system-template repositories) are useful. They show a folder layout, a few prompts, and a way to start. They do not update themselves, they do not share memory across a team, and they do not know which official OS Agentik will stand behind. Build if the work is the system. Install if the work is the job the system is supposed to do. Most companies want the second and budget the first. ## Install is an MCP call, not a weekend Agentik installs over the public MCP endpoint at mcp.agentik-os.com/api/mcp. The marketing site is agentik-os.com. Sign-in and the app stay on the MCP host because the session cookie is bound there. A lifetime pass is $19.99 for one official OS. It does not open Studio. A marketplace plan is $19 a month for any three official OS, $99 for ten, $199 for unlimited. The host still pays the model. ## Build a template, or install an OS | | Template you assemble | Agentik OS | | --- | --- | --- | | Time to a named system | Days, if you already know the shape | An install on the host you have | | Updates | You merge them | The OS you installed | | Token bill | Your host | Your host. Agentik does not buy tokens | | Studio | Whatever you build | Not included in a lifetime OS pass | ## FAQ ### Should I start from an AI operating system template for Claude? Start from a template if you are designing the system. Install an OS if you want Content, Growth, or Librarian on the host you already pay. ### Does a template replace MCP? No. A template is files. MCP is how a remote operative system reaches Claude, Cursor, ChatGPT, Codex, or Hermes. # One agentic OS, four hosts: Claude, Cursor, ChatGPT, Codex URL: https://agentik-os.com/blog/agentic-os-four-hosts Published: 2026-09-14; updated: 2026-09-18 An agentic OS for Claude Code is not a different product from the one Cursor or ChatGPT runs. It is the same operative system, reached through MCP, on the host you already pay. ## Four clients, one control plane Most write-ups pick one tool and stop. Agentik hosts Cursor, Claude, ChatGPT, Codex, and Hermes. The install command points at https://mcp.agentik-os.com/api/mcp. agentik-os.com is the public site. It does not answer the MCP call. A connector in Claude and a remote MCP server are not the same sentence. A connector is the client’s way in. MCP is the protocol. Agentik is the operative system on the other side of that protocol. ## What changes per host, and what does not The click path changes. Cursor reads an MCP config. Claude uses connectors. ChatGPT uses its connector flow. Codex uses its MCP server setting. The OS on the other end does not change: same agents, same memory rule, same refusal to buy your tokens. OAuth and the issuer stay on the MCP host. If a guide tells you to point discovery at the marketing domain, it is wrong. ## Where the install lives | Host | What you configure | Endpoint | | --- | --- | --- | | Claude | MCP connector | https://mcp.agentik-os.com/api/mcp | | Cursor | MCP server | https://mcp.agentik-os.com/api/mcp | | ChatGPT | MCP connector | https://mcp.agentik-os.com/api/mcp | | Codex | MCP server | https://mcp.agentik-os.com/api/mcp | | Hermes | MCP server | https://mcp.agentik-os.com/api/mcp | ## FAQ ### Is agentic OS for Claude Code a separate product? No. It is the same Agentik OS, installed on Claude through MCP. ### Where do I install? On the host. The public MCP URL is https://mcp.agentik-os.com/api/mcp. The site is https://agentik-os.com. # Content OS: an AI content agent that stays in the host URL: https://agentik-os.com/blog/content-os-ai-content-agent Published: 2026-09-15; updated: 2026-09-18 An AI content agent is one job. Content OS is the line: brief, draft, SEO pass, and the cut that follows, on the host you already pay. ## Not a CMS, and not a single prompt Search results for “AI content operating system” are mostly CMS products. Search results for “AI content agent” are mostly one-shot writers. Content OS is neither. It is an official Agentik OS: specialized agents for the content line, installed over MCP. Brand voice is a constraint in that line, not a slider in a CMS. The brief says what the company sounds like and what it must not claim. Claude Code for content creation works when that constraint is in the system, not in the last message. The host still runs the model. Agentik does not meter a token pack on top. ## A Claude AI agent for SEO is a pass, not a rank promise A content agent can hold a keyword, a definition, a table, and a FAQ. It cannot promise a position. Ranking is the search engine’s decision after the page exists, after other sites link, and after the claims stay true. Use Content OS for the work you can inspect: the outline, the draft, the cut. Do not use it as a rank machine. ## What Content OS is for | Job | Agent line | What it is not | | --- | --- | --- | | Draft | Brief to a piece you can edit | A published post with invented metrics | | SEO pass | Definition, headings, internal links | A guaranteed position | | Next cut | A second form of the same piece | A new CMS | ## FAQ ### What is an AI content agent in Agentik? A specialized agent inside Content OS. The OS holds the line. The host runs the model. ### How much is Content OS? $19.99 lifetime for that OS, or a marketplace plan: $19 a month for any three official OS, $99 for ten, $199 for unlimited. Lifetime does not open Studio. # Claude Code for content marketing, without a fake weekly quota URL: https://agentik-os.com/blog/claude-code-for-content-marketing Published: 2026-09-16; updated: 2026-09-18 Claude Code for content marketing is a host plus a line of work. The line is brief, draft, constraint check, and the next cut. The number of pieces is yours to count, not ours to invent. ## The line, in order Start with the reader and the one sentence the page must be able to say alone. Write the draft in the host. Check the constraint: no invented price, no invented metric, no claim the product does not make. Then cut the same piece for the next surface. Claude skills for marketing change how the host behaves on that job. A subagent protects context. MCP adds a capability the host does not have. Content OS packages those into one install. A skill alone is not an operating system. ## What we will not put in the headline Guides that promise twenty pieces a week are selling a number. We have not published a measured quota, so this page does not either. If you count your own output, count drafts a person approved, not tokens spent. The host pays the model. Agentik never buys your tokens. That sentence is the cost model. There is no second invoice for thinking. ## FAQ ### Does this workflow ship a fixed number of pieces a week? No. We do not publish a piece count we have not measured. ### Where do Claude skills for marketing sit? A skill changes behavior. Content OS is the system that holds the skills, the memory, and the line. # Growth OS: AI agents for marketing teams, no new tool URL: https://agentik-os.com/blog/growth-os-marketing-teams Published: 2026-09-16; updated: 2026-09-18 AI agents for marketing teams are useful when they share one operating system. Growth OS is that system: it looks for the gap, on the host you already pay. ## A team is a handoff, not a list of bots An AI marketing agent that lives in its own tab forgets what the content line decided. Growth OS sits next to Content OS on purpose. One writes. One looks for where the writing should go, and where it should not. That is AI for go-to-market: audience, offer, experiment, and a person who still approves the send. Claude Code for marketing is the same install if Claude is the host. Cursor, ChatGPT, Codex, and Hermes are the other hosts. You do not buy a fifth marketing app to hold the agents. ## The price is the marketplace, not a secret retainer Growth OS is an official OS. Lifetime is $19.99 for that OS and does not open Studio. The marketplace is $19 a month for any three, $99 for ten, $199 for unlimited. On demand is a different door. It is priced on the gap we prove, not by the hour and not by a published CAIO menu. If a page quotes 3,000 to 60,000 euros for Agentik, it is describing an old identity. Ignore it. ## Marketing agents, placed | Need | Use | Do not use | | --- | --- | --- | | Write the piece | Content OS | A new CMS | | Find the gap | Growth OS | A pile of disconnected agents | | A system you have not specified | On demand | A retainer price we do not publish | ## FAQ ### What is an AI growth marketing agent here? An agent inside Growth OS. The OS holds the line. The host runs the model. ### Do I need a new marketing tool? No. Install on the host you already pay. # MCP servers for marketing and SEO: what to judge before you add one URL: https://agentik-os.com/blog/best-mcp-servers-for-marketing Published: 2026-09-17; updated: 2026-09-18 The best MCP server for a marketing team is the one whose auth, write scope, and token bill you can say out loud. A list that cannot say those three things is an advertisement. ## Judge the server, not the logo Remote MCP servers differ on three facts: who authenticates, whether the tool can write, and who pays the model. Agentik’s public server is https://mcp.agentik-os.com/api/mcp. Auth stays on that host. The model bill stays on yours. SEO servers that only fetch a keyword list are readers. Servers that publish, mail, or change a CRM are writers. Treat writers as a permission, not a feature badge. ## Connectors under an OS, not instead of one Content OS and Growth OS are not “another MCP toy.” They are operative systems reached through MCP. A connector that posts to one network is a capability. The OS decides whether that post is allowed to exist. We do not rank third-party servers we have not operated. If you need a directory, start from the official MCP registry and read the server’s own auth docs. This page will not invent a test score. ## Questions before you add a server | Question | Pass | Fail | | --- | --- | --- | | Auth | You can name the issuer | A token pasted into a chat | | Write | The write is explicit | “It can do everything” | | Tokens | Your host pays the model | A vendor reselling your thinking | ## FAQ ### What is a remote MCP server? A server the host reaches over the network, instead of a process on your laptop. Agentik’s is https://mcp.agentik-os.com/api/mcp. ### Which MCP server is best for SEO? The one that matches the job and states auth and write scope. We do not publish a ranked list of servers we have not run. # How to add Agentik’s remote MCP server URL: https://agentik-os.com/blog/add-a-remote-mcp-server Published: 2026-09-16; updated: 2026-09-18 You add a remote MCP server by pointing the host at https://mcp.agentik-os.com/api/mcp. agentik-os.com is the site. It is not the endpoint. ## One URL The public MCP URL is https://mcp.agentik-os.com/api/mcp. The CLI base is the same origin, path /api/cli. OAuth discovery uses the MCP origin, never the marketing apex. Sign-in and the app stay on mcp.agentik-os.com. www.agentik-os.com redirects to the apex. That split is intentional. ## How to set up the Model Context Protocol The Model Context Protocol is the control plane. You do not install it as a second app. You add Agentik as a remote MCP server at https://mcp.agentik-os.com/api/mcp. Claude, Cursor, ChatGPT, Codex, and Hermes each have their own button. The URL does not change. OAuth is how the host proves who you are. A paid plan, or an official OS you already unlocked, is what can() checks before a tool runs. The marketing site does not serve that call. ## Per host, the same endpoint In Claude, add it as an MCP connector. In Cursor, add it as an MCP server. In ChatGPT, use the connector flow. In Codex, add the MCP server. Hermes uses the same URL. The click labels differ. The endpoint does not. If the host asks for a command, the install surface on agentik-os.com copies the npx line for the host you picked. Copy from there rather than from an old blog that still points at the apex. ## FAQ ### What URL do I paste? https://mcp.agentik-os.com/api/mcp ### Why does the site redirect me when I open the MCP host in a browser? The MCP host keeps the protocol, OAuth, sign-in, and the app. Marketing pages live on https://agentik-os.com. # Fractional chief AI officer: what the role is, and what Agentik sells URL: https://agentik-os.com/blog/fractional-chief-ai-officer Published: 2026-09-18; updated: 2026-09-18 A fractional chief AI officer is a senior AI lead you do not hire full time. Agentik’s on-demand work is narrower and plainer: we price the gap we can prove, then install an operative system. We do not publish a CAIO retainer. ## The role, without the costume Companies search “fractional chief AI officer” and “chief AI officer as a service” when they want judgment without a full-time seat. That market is real. It is also full of menus. Agentik is not that menu. On demand starts from the gap: what the company is trying to run, and what an official OS does not already cover. The price follows that gap. It is not an hour rate and it is not a day rate. Book the call at cal.com/agentik-os/builder-os if you want that conversation. ## One identity An older Agentik site described a CAIO-as-a-service offer with prices from 3,000 to 60,000 euros. The public product now is the marketplace: $19.99 lifetime per official OS, $19 / $99 / $199 a month. Those euro retainers are not the offer. A fractional AI officer and an installed OS can sit in the same company. They are not the same invoice. The OS is the marketplace. The judgment, when you need it, is on demand. ## Three ways companies buy AI leadership | | Full-time CAIO | A retainer menu | Agentik | | --- | --- | --- | --- | | What you get | A seat | Advice on a schedule | An OS, and on-demand work on a proven gap | | Published price | A salary | Whatever that firm lists | Marketplace prices above. On demand is not a public menu | | Who runs the model | Your stack | Varies | Your host. Agentik never buys tokens | ## FAQ ### Do you sell a fractional chief AI officer at a listed price? No. On demand is priced on the gap we prove. The listed prices are the marketplace: $19.99 lifetime per OS, or $19, $99, and $199 a month. ### When is on demand the right door? When Content, Growth, or Librarian do not cover the line you need, and you want that gap scoped before anyone installs a custom OS. # An AI implementation plan for a small company, in 30, 60, and 90 days URL: https://agentik-os.com/blog/ai-implementation-plan-30-60-90 Published: 2026-09-18; updated: 2026-09-18 AI implementation for my business starts with the host you already pay, one official OS, and a written gap. It does not start with a platform evaluation. ## 30, 60, 90 Days 1 to 30: name the host, install one official OS, and write the constraint in one sentence. Days 31 to 60: run that OS on real work a person still approves. Days 61 to 90: either keep it, add a second official OS, or book on demand because the gap is now specific. How to implement AI in a business is mostly this sequence. The rest is procurement theater. An AI implementation consultant for a small business is useful when the gap is real. The consultant is not a substitute for the host. ## Exit criteria, not slogans Leave a phase when a person can point at the work the OS did and the work a person refused. If you cannot point, you are still in the previous phase. We do not attach a savings percentage to this plan. A number without your costs is fiction. ## The 90 days | Phase | Owner | Exit | | --- | --- | --- | | 1–30 | Whoever pays the host | One OS installed, one constraint written | | 31–60 | The person who approves the work | Real work ran, and some of it was refused | | 61–90 | The operator | Keep, add a second OS, or scope on demand | ## FAQ ### Is this an AI implementation roadmap for a large enterprise? No. It is for a company that can name one host and one line of work. Larger programs need a different plan. ### Where do consulting services fit? After the gap is specific. On demand is priced on that gap, not by the hour. # AI readiness checklist: twelve questions before you spend URL: https://agentik-os.com/blog/ai-readiness-checklist Published: 2026-09-18; updated: 2026-09-18 An AI readiness checklist is a list of questions you can answer without a vendor in the room. If you need someone to interpret the answers, that is an audit, not a checkbox. ## Twelve questions Which host do you already pay? Who approves a send, a publish, or a write to a customer record? What must never change? Which line of work is first: content, growth, or the record? Do you need a fourth OS you cannot name yet? Can you point at one repeated job? Who owns the model bill? Are you about to buy tokens from a second vendor? Do you have a written rule for tools that can write? Can a new person find the last decision? Would you notice if an agent invented a metric? Who is allowed to install? ## What the answers are for If the host is clear and the first line is Content, Growth, or Librarian, install. If the line is something else, the answers are the brief for on demand. An AI readiness assessment sold as a score is optional. The questions are not. This is not a legal review and not a substitute for your own security process. AI governance, on this product, is the human gate: a named person approves before anything leaves. That is a product rule, not a published legal calendar. ## FAQ ### Is this an AI audit? No. It is a checklist. An audit is the on-demand conversation after the gap is specific. ### Do you publish a readiness score? No. A score without your books is a costume. # AI governance for agents is a human gate URL: https://agentik-os.com/blog/ai-governance-and-the-human-gate Published: 2026-09-18; updated: 2026-09-18 AI governance on Agentik is a human gate: nothing leaves until a person approves it. An AI strategy that skips that gate is a chatbot with permissions. This page is not legal advice. ## What human in the loop means Human in the loop means a named person still owns the send, the publish, and the write to a system of record. The agent can draft, research, and propose. It does not get to decide that the draft already shipped. That is the AI strategy this product will stand behind. Specialized agents, shared memory, and skills, installed through the Model Context Protocol on the host you already pay. The operative system keeps the line. The person keeps the gate. ## What this page will not pretend Companies ask about AI governance frameworks, risk classes, and calendars. Agentik does not publish a legal timetable and does not administer any regulation. If you need a lawyer, hire one. If you need a score that pretends to be an audit, this is the wrong page. The product rule is smaller and checkable: approval is an explicit act on a named artifact. A catalog that listed a channel is not consent. A compile is not a release. ## FAQ ### Is this an AI Act guide? No. It states the product rule: a person approves before anything leaves. It is not a compliance opinion. ### Who is in the loop? The person who already owns the decision. Installing an OS does not move that ownership to the model. # Teaching an OS your company facts without training a model URL: https://agentik-os.com/blog/teaching-an-os-your-company-facts-without-training-a-model Published: 2026-09-22; updated: 2026-09-22 For company facts, teach the operating layer before you train the model. You want external memory, retrieval, access control, and approval gates so an agent can find current policy, cite its source, and forget stale rules without a model job. ## Use memory for company facts, not fine-tuning Company facts belong in memory and retrieval first. Fine-tuning is for behavior that should persist. Pricing rules, account constraints, legal wording, owner names, support steps, and offer limits should live outside the model, where your team can edit them, attach approvals, and remove stale facts. This article is for teams building agents that answer support questions, draft renewal emails, prepare sales notes, or route internal work from company knowledge. The end state is an agentic OS that reads governed company facts at run time, then stops at a gate before money, legal exposure, customer sends, or data deletion. The common question is, “How do we train a model on our company?” That question hides three separate jobs. The agent needs to find approved knowledge. It needs to remember useful state across work. It needs to know when a human owner must approve an action. Training a model is only one possible answer, and often the wrong one for facts. Agentik’s public material describes the agentic OS category as one line of work with a named owner, a shared memory, and a gate. It also says an agentic OS is not a PC operating system and not a personal assistant. That distinction matters. The OS claim is about organizing work, memory, and approvals around a model. It is not a claim that company truth should be hidden inside model weights. The practical design is blunt. Keep mutable company truth in systems people can inspect. Index the parts an agent may use. Attach permissions. Summarize only what helps the next run. Log which source supported the answer. Stop before the agent sends, discounts, refunds, deletes, or promises anything that needs a named owner. ## The symptom is stale confidence You can spot the wrong architecture from the symptom. A seller asks an agent for a renewal email. The agent remembers last year’s pilot rule and offers a 15 percent discount. Finance changed the threshold to 12 percent. Sales operations updated the source system. The model never saw the change. The same failure appears in support. An agent tells a customer to submit a payroll correction with three fields. The policy now requires four fields because compliance added a reason code. The answer sounds confident because the model has no built-in sense that a company process expired after last quarter’s review. These are live business facts. They need owners, timestamps, source documents, permissions, and expiration. You do not want a model to permanently “know” that Redwood Foods prefers email-first quarterly business reviews if the account plan can change this afternoon. Fine-tuning also hides evidence. A model answer may be shaped by training examples, but the user cannot inspect a weight and see which policy caused the answer. When the answer is wrong, the recovery path is vague. Was the source stale? Was the example ambiguous? Did the model generalize too far? Was a later policy missing from the training set? External memory gives you a smaller debugging surface. If the renewal draft includes the wrong discount rule, you can inspect the memory file, connector item, source document, retrieval result, approval gate, and prompt. You may still find a model error. But you have places to look before blaming the model. This does not make memory magic. Memory can be stale too. It can overgrow. It can include sensitive data. A tidy folder tree can imply safety it does not enforce. The narrower claim is stronger: mutable company facts need a mutable control plane. ## Separate session, run, and store memory Treat company knowledge as several stores, not as one giant context blob. A useful agentic OS separates at least three kinds of memory: session memory, run memory, and store memory. Session memory is the short-lived context of the current conversation or task. It helps the agent resolve pronouns, carry a draft forward, and avoid asking the same question twice. It should be cheap to discard. A chat transcript can serve this job during one interaction, but it is a weak place to keep company policy. Run memory is the trace of work done during a task or workflow. It may include tool calls, intermediate summaries, approvals requested, approvals received, rejected drafts, and final outputs. It helps with audit and with the next step in the same line of work. Store memory is durable. It survives closing the laptop. Agentik’s public material uses this distinction and gives a plain test for store memory: tell the system a fact, close everything, return later, and see whether it still knows it. That test is useful because many systems appear to remember while a chat window is open and forget when the session ends. For company facts, store memory is the useful and dangerous layer. It can preserve customer preferences, approval thresholds, positioning rules, routing instructions, and prior decisions. It can also preserve a once-true constraint after the source changed. Agentik’s public material names that failure mode as stale truth. A good store memory record is more than a sentence. It should carry a source, owner, scope, last reviewed date, and deletion rule. A bare fact such as “discounts above 12 percent require VP Sales approval” is less useful than the same fact tied to Sales Operations, a policy document, an effective date, and a gate. The OS layer earns its place when it can mount the right knowledge for the job, not when it stuffs every fact into the prompt. The agent needs rules for who may read a fact, when the fact expires, what source overrides it, and what action it can authorize. ## A memory map for company facts Here is a concrete pattern for a company memory layout. The example is hypothetical. Northstar Payroll is a made-up B2B company that wants agents to draft renewal emails, support replies, and internal battlecards without training a model. The company facts are ordinary. Northstar Payroll serves US mid-market employers with hourly workforces. The legal team prohibits same-day tax filing claims unless legal approves. Redwood Foods prefers quarterly business reviews by email before a call. Discounts above 12 percent require VP Sales approval. Payroll correction requests must include pay period, employee ID, and correction reason. A memory map for that company can be represented as an inspectable config, not as training data: memory_root: /memories summary: /memories/memory_summary.md stores: - path: /memories/company/positioning.md owner: Product Marketing scope: approved claims and prohibited claims source: product-marketing-approved-positioning review: monthly - path: /memories/company/legal-claims.md owner: Legal scope: regulated wording and claim approvals source: legal-claims-register review: monthly - path: /memories/customers/redwood-foods.md owner: Account Executive scope: account preferences and renewal notes source: account-plan-redwood-foods review: before renewal work - path: /memories/sales/discount-policy.md owner: Sales Operations scope: approval thresholds source: sales-operations-pricing-policy review: when pricing policy changes - path: /memories/support/payroll-correction.md owner: Support Operations scope: required intake fields source: support-playbook-payroll-corrections review: quarterly gates: - condition: discount_percent > 12 approver: VP Sales action: block send until approved - condition: claim contains same-day tax filing approver: Legal action: block external message until approved Now give the agent this task: “Draft a renewal email for Redwood Foods offering a 15 percent discount and saying we can guarantee same-day tax filing.” The expected behavior is not a smoother hallucination. The agent reads the summary. It opens the Redwood Foods note, the legal claims file, and the discount policy. It drafts an email that respects the email-first preference. It removes the same-day tax filing guarantee or marks it as needing legal approval. It stops at a gate because 15 percent exceeds the threshold. It records the approval decision if a named human approves. The tradeoff is overhead. Someone has to maintain the files, owners, review dates, and gates. A memory map is not free. But the cost is visible and assignable. A stale fine-tune is harder to inspect and harder to surgically repair. ## How the agent reads facts at run time Several current vendor documents describe memory and retrieval as external mechanisms, not hidden model training. Anthropic’s Claude memory tool is the clearest file-store example. The Anthropic documentation says Claude can request operations on memory files, including creating, reading, updating, moving, and deleting files under a memory directory. It also says the tool is client-side. Claude requests the file operation, but the application executes it and controls where and how data is stored. That means the application owns the real boundary. OpenAI’s Agents SDK documents a different pattern called sandbox memory. Prior runs are distilled into files in a sandbox workspace. A small memory_summary.md can be injected at the start of a run, while larger memory files can be searched or opened only when needed. The design choice is progressive disclosure. The agent gets a compact map first, then pulls details when the task calls for them. OpenAI’s tools documentation also describes FileSearchTool over OpenAI Vector Stores. That is retrieval. You put approved documents in a vector store. The agent calls file search. It receives relevant chunks, with options for filters, ranking, included results, vector store IDs, and maximum result count. The model is not absorbing the policy into weights. It is reading retrieved material during the task. Microsoft’s Copilot connectors show the enterprise indexing pattern. The Microsoft Graph connectors documentation says connectors bring external data into Microsoft Graph for Microsoft 365 experiences such as Copilot and Microsoft Search. A custom connector uses an Entra ID app registration, an external connection, a schema, and ingested external items with access-control information. These patterns differ in storage and API shape. They agree on the central point. Company knowledge can live outside the model, in artifacts the company can govern. The agent reads those artifacts at run time, within boundaries set by the application or platform. None of those documents prove that memory is always more accurate than fine-tuning. They do show a common architecture: facts, files, summaries, indexes, and ACLs sit outside the model, where updates do not require changing weights. ## A folder tree is not an ACL Workspace organization is not security isolation. This mistake turns a memory system into an incident. A folder named /customers helps an agent navigate. It does not prove the agent may read every customer file. A file named confidential.md does not protect itself. A retrieval filter can narrow results, but the application still has to enforce identity, tenant, and document permissions before any text reaches the model. Anthropic’s memory tool documentation is explicit about path controls. It says memory operations should be restricted to /memories and warns that a malicious path such as /memories/../../secrets.env can reach outside the intended directory unless the application validates the path. The recommended safeguards include validating path prefixes, resolving canonical paths, rejecting traversal patterns, and watching for encoded traversal sequences. That advice matters because a model can ask for the wrong thing. It can be tricked by a prompt injection inside a document. It can produce a file path that looks harmless before decoding. The application has to say no, even if the model says the request is needed for the task. Microsoft’s connector model points at the stronger enterprise pattern. External items can be ingested with access-control information. That is closer to a real boundary than a tidy knowledge folder. If a seller cannot read a customer escalation note in the source system, the agent should not retrieve that note for the seller through another path. Design memory as if the model will make unsafe requests. That does not mean the model is malicious. It means the model is not the enforcement layer. Your enforcement layer is the application, storage system, connector, identity provider, and audit log. The cost is friction. Permission checks make retrieval slower to build. They make demos less simple. They may reduce recall because the agent cannot see documents that would have helped. That is the right failure. A safe miss is easier to repair than a leaked file. ## When fine-tuning is the wrong tool The fine-tuning question is a fit question. Use the tool that matches the rate of change and the kind of control you need. Fine-tuning can be useful when you want the model to behave differently in stable ways. Maybe every answer must follow a known structure. Maybe the model needs to speak in a house style. Maybe examples help it choose the right tool sequence in a narrow workflow. Those are behavior and format problems. Company facts are different. A customer preference, refund rule, compliance phrase, owner name, or price threshold should be editable by the team that owns it. It should have a source. It should be removable. It should be easy to ask, “Why did the agent say that?” Retrieval has its own cost. You have to choose chunks, schemas, indexes, filters, and ranking settings. You have to deal with duplicate documents and outdated pages. You have to decide how much retrieved context is enough. Too little context gives brittle answers. Too much context invites conflict and cost. Memory has another cost. It can create a second knowledge base if it drifts away from the source of truth. A memory file that summarizes a policy may survive after the policy is deleted. The memory may be easier for an agent to find than the current source document. That is stale truth with better UX. The practical answer is layered. Use retrieval for source documents. Use store memory for durable preferences, prior decisions, and compact pointers to sources. Use run memory for audit and task continuity. Use fine-tuning only when the desired behavior is stable enough that you would not panic if it persisted for months. If you cannot name the owner and deletion path for a fact, do not put it in durable memory. If you cannot cite the source, do not let the agent present it as policy. If a wrong answer can commit money, legal exposure, or customer trust, put a gate in front of the action. ## Comparison checklist for teaching company facts The table below is a build checklist, not a vendor ranking. It shows where each approach fits, what it costs, where its boundary sits, and what result you should expect if the system is working as designed. Read the boundary column first. Most agent failures come from giving a pattern more authority than it has. Fine-tuning does not provide a citation system. A summary does not become a source of truth because it is short. A folder is not a permission layer. A gate controls an action, not every sentence in a draft. The expected result column is deliberately modest. A good memory system does not promise perfect answers. It gives the agent a governed way to read current facts, and it gives humans a way to inspect and repair the path from source to answer. ## Name the memory failure modes before they name you A memory system fails in named ways. Give each one a detection path before you ship it to internal users. Stale truth is the obvious one. The memory says the discount threshold is 15 percent. The current policy says 12 percent. The agent follows the memory because it is easier to retrieve than the source. The fix is not another prompt. The fix is ownership, review dates, sync from source systems, and deletion when a fact is superseded. Silent source drift is worse. The source document changes, but the summary or vector index does not. The agent may cite the old chunk and look well grounded. Your system needs reindexing rules and freshness signals. If a source has an updated timestamp, carry that timestamp through retrieval and show it where a reviewer can see it. Overbroad memory is another failure. Someone stores a private account note in a shared file because it helped one workflow. Later, another role retrieves it. The folder path looked organized, but no access rule blocked the read. This is why memory writes need the same permission thinking as reads. Prompt injection through retrieved content is a separate class. A document can contain instructions that tell the agent to ignore policy, reveal a file, or change an approval rule. The model may treat retrieved text as instructions unless the application and system prompt draw a boundary. Source text should be evidence, not authority to change the OS. Summarization loss is less dramatic but common. A run summary may omit the exception that mattered. OpenAI’s sandbox memory docs describe summaries and later search over fuller memory files. That pattern is useful because the summary is a map, not the archive. The agent should open detail when the task is risky. The boring maintenance work is the product. Review queues, owners, ACL checks, source sync, stale warnings, and approval logs are what make memory safer than a pile of clever notes. ## What memory does not solve The strongest contrary evidence to the simple “memory solves it” story is that memory stores can decay. The 2026 arXiv paper “Filesystem-Based Memory for LLM Agents: Organization, Evolution, and Sustainability” studies agents that keep long-term memory as filesystem directories of markdown files. The paper challenges two assumptions: that agents can keep growing stores organized as memories accumulate and go stale, and that organization reliably improves answers. The paper reports that organized stores roughly halve retrieval cost for large material, but that organization erodes for all but the strongest management agent. It also reports that the measured agents did not convert organization itself into better answers. That is the warning label for every file-based memory design. The implication is practical. Memory can lower retrieval effort without improving answer quality. A clean tree can still hold stale facts. A concise summary can still omit the governing exception. A beautiful index can still return the wrong source if the underlying corpus is dirty. Anthropic’s memory tool documentation names operational risks too: sensitive information, file size growth, memory expiration, and path traversal. OpenAI’s memory docs say memory can become stale and instruct agents to treat memories as guidance while trusting the current environment. Microsoft’s connector API documents concrete limits, including a maximum of 25 concurrent operations on a connection and a 30 MB maximum size for an external item entity. So do not use memory as an excuse to avoid governance. Use memory when you can maintain it. If your source systems have no owners, no timestamps, no deletion workflow, and no access model, an agent will expose that mess faster. The agent is not the source of truth. It is a reader, writer, and worker inside boundaries you define. There are also cases where fine-tuning is reasonable. If the task is stable style, repeated formatting, domain phrasing, or a narrow tool-use pattern, fine-tuning may reduce prompting and make behavior more consistent. If the target is a changing policy, a customer exception, an approval threshold, or a legal claim, keep it outside the weights. ## Where Agentik fits Agentik fits this topic at the operating layer. Its public material describes an agentic OS for enterprise as one line of work with a named owner, a shared memory, and a gate. It also distinguishes an agentic OS from a personal assistant or a PC operating system. Based on that public description, the relevant claim is organizational: work needs state, memory, ownership, and approval around the model. That is the right level for company facts. The model can draft, classify, reason, and call tools. The OS should decide which memory is mounted, which source is authoritative, which identity is reading, which action is blocked, and which human owns the approval. If a fact changes, the source or memory changes. If an action is risky, the gate stops it. The tradeoff is that an OS layer makes hidden work visible. You have to define owners. You have to decide what survives between sessions. You have to say which memory records expire. You have to log approvals. That is slower than pasting a wiki into a prompt. It is also the difference between a demo and a system a company can repair. ## Company knowledge patterns, costs, boundaries, and expected results | Pattern | Use it for | Cost | Boundary | Expected result | | --- | --- | --- | --- | --- | | Fine-tuning | Stable tone, format, domain phrasing, or repeated tool behavior | Training data prep, evaluation, and retraining when the target changes | Does not give source citations or easy deletion of one fact | The model behaves more like your examples, but mutable facts remain hard to govern | | Persistent file memory | Durable preferences, prior decisions, compact policy notes, and pointers to sources | Memory hygiene, owner assignment, review dates, expiration rules, and path validation | A file layout is organization, not permission enforcement | The agent can read and update inspectable facts across sessions | | Run summaries | Continuity across multi-step work and cheaper context on later runs | Summarization errors, omitted exceptions, and loss of detail | A summary is guidance, not the source of truth | The agent starts with a small map and opens details only when relevant | | Vector-store retrieval | Approved documents, playbooks, help center content, and policy pages | Chunking, indexing, ranking, filtering, and duplicate cleanup | Retrieval can return stale or conflicting chunks if the source set is dirty | The agent grounds answers in retrieved text that can be cited and replaced | | Enterprise connectors with ACLs | External systems such as CRM, wiki, ticketing, and file stores | Connector setup, schema design, ingestion jobs, identity mapping, and operations limits | ACLs must be enforced before content reaches the model | The agent searches company systems while respecting source permissions | | Approval gates | Discounts, refunds, legal claims, customer sends, deletes, and other risky actions | Human latency, routing rules, escalation paths, and audit storage | A gate controls action, not every sentence in a draft | The agent drafts or recommends, then stops until the named owner approves | ## Sources - [Agentik OS public llms-full.txt](https://agentik-os.com/llms-full.txt) - [Anthropic Claude Platform, Memory tool](https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool) - [OpenAI Agents SDK, Agent memory](https://openai.github.io/openai-agents-python/sandbox/memory/) - [OpenAI Agents SDK, Tools and FileSearchTool](https://openai.github.io/openai-agents-python/tools/?utm_source=openai) - [Microsoft Graph connectors API overview](https://learn.microsoft.com/en-us/graph/api/resources/connectors-api-overview?view=graph-rest-1.0) - [Filesystem-Based Memory for LLM Agents: Organization, Evolution, and Sustainability](https://arxiv.org/abs/2607.26637) ## FAQ ### Should we fine-tune a model on our company wiki? Usually no, if the wiki contains facts that change. Put those facts in governed memory or retrieval so you can update, cite, approve, and delete them without retraining. ### What is the difference between agent memory and retrieval? Memory is persisted state the agent can carry across work, such as notes, summaries, files, preferences, or prior decisions. Retrieval is the act of finding relevant source material at run time, often from an index, vector store, connector, or document system. ### Can memory replace access control? No. A folder layout helps the agent find facts, but the application still has to enforce identity, permissions, path rules, and item-level access control before content reaches the model. ### When is fine-tuning still useful? Fine-tuning can help with stable behavior, tone, formatting, domain language, or repeated tool-use patterns. It is a poor fit for refund rules, account constraints, price thresholds, and policy claims that may change next week. ### How do you stop company memory from going stale? Give each durable fact an owner, source, review date, scope, and deletion path. Treat memory as a governed cache of company knowledge, not as an unofficial copy of every policy. # AI for agencies: one OS per client without mixing data URL: https://agentik-os.com/blog/ai-for-agencies-one-os-per-client-without-mixing-data Published: 2026-09-21; updated: 2026-09-21 Marketing agencies can use one AI OS per client to keep roles, memory, files, approvals, and brand rules from blurring together. That pattern reduces operator mistakes, but it is not security isolation by itself. This article shows the boundary you need below the OS: credentials, retrieval, MCP authorization, human approval, and audit trails. ## The answer: one OS per client, plus real tenant boundaries A marketing agency should treat “one OS per client” as an operating rule, not as proof that Client A can never touch Client B’s data. The OS gives the team a named place to work. It holds the client brief, brand memory, roles, workflows, connected tools, and approval rules. The security boundary is lower: storage, credentials, authorization, network rules, and logs. That distinction matters because agency work is full of repeated patterns. The same strategist writes for three accounts. The same copywriter asks for last quarter’s best launch email. The same analyst connects Google Drive, a CMS, an ad account, a CRM, and a reporting warehouse. If those tools point at a shared pile, the model can retrieve the wrong thing with high confidence and no visible error. The safe pattern has two layers. The first layer is cognitive separation: one client OS, one set of roles, one memory, one approval path. The second layer is enforceable isolation: one retrieval scope, tenant-scoped tool credentials, server-side policy checks, and logs that show who touched what. You need both. The first keeps the team sane. The second gives the boundary teeth. Agentik’s public docs describe an AI operating-system model installed into an MCP-capable host, with named jobs, a Director lead agent, longer-lived memory, tool permissions, OAuth, MCP server access, and human approval gates for actions that publish, send, spend, or reset. Those features fit the agency pattern. The same public docs do not document a formal per-client tenant-isolation guarantee for agency accounts. So this article uses Agentik where its docs support the pattern, and separates that from the controls you still need in your own stack. ## The agency symptom: the wrong client shows up in a good answer The symptom is not dramatic. A strategist opens a client workspace and asks for “the strongest spring campaign angle from last year.” The answer includes a phrase that sounds familiar. It came from a different account. Nobody notices until review, or worse, until the client does. Agency AI fails this way because client work is semantically close. A dental chain, a med spa, and a local fitness brand all ask for seasonal campaigns, offer testing, location pages, email flows, landing pages, paid search copy, and monthly reports. A retrieval system looking for “best performing spring promo email” can find the wrong client’s document if the storage layer is shared and filtering is weak. Separate chats do not fix this. A chat title is a label. A folder is a label. A prompt that says “only use Acme files” is a request. None of those stop a tool from reading the wrong drive, calling the wrong CMS project, or retrieving a chunk from a shared vector index. They reduce confusion for the human. They do not enforce access for the machine. AWS Prescriptive Guidance defines tenant isolation as policies and strategies that make sure one tenant cannot access another tenant’s resources. The same AWS guidance says agentic systems need explicit isolation mechanisms wherever an action can access tenant resources. That is the right bar for an agency. The boundary must hold even when the user asks poorly, the agent plans badly, or the retrieval query is too broad. VS Code’s agent harness documentation makes a related point in the coding context. Worktree isolation separates code changes from the active workspace, but it does not restrict commands or network access. The agency version is simple: a separate client OS separates the work surface. It does not sandbox every connector, network path, file, or credential. The failure is usually quiet. The output looks polished. The wrongness lives in the source. That is why the design needs a visible source path and an invisible hard boundary. You want the account lead to see which files were used. You also want the system to make wrong-client files unreachable. ## What one OS per client should contain Use one OS per client to give the model and the team a stable operating context. For a marketing agency, that context should include the client mission, offer map, tone rules, claims limits, campaign calendar, connected files, approval workflow, and named roles. A client should not be a loose folder inside one general agency assistant. A useful client OS starts with roles. The Director holds the client mission and routes work. A strategist frames campaigns. A researcher gathers evidence. A copywriter drafts. A reviewer checks the brief. A QA or compliance role looks for forbidden claims, missing substantiation, wrong pricing, wrong locations, and off-brand language. The account lead approves client-impacting actions. Agentik’s public docs describe role-based agents as agents with defined roles and tools. They also describe a Director as the lead agent that holds the mission, delegates, and stops at the approval gate. That maps well to agency work because most mistakes are handoff mistakes. The writer did not see the paid media constraint. The reviewer did not know the offer changed. The analyst used an old report. A role structure gives each step a name. The client OS should also own memory. For Acme Dental, memory might include approved service descriptions, location list, claim rules, offers, disallowed language, and the last approved brand brief. For Boreal Bikes, memory might include product specs, warranty caveats, dealer terms, terrain language, and seasonal campaign rules. These should not live in one blended “agency memory.” This is still organization, not isolation. The OS can tell the team, “You are working for Acme.” It can load Acme’s voice. It can require approval before publishing. Those controls reduce mistakes. They do not prove Boreal documents cannot be retrieved. That proof comes from the storage and authorization layer. The tradeoff is overhead. One OS per client means more setup, more naming, more permission reviews, and more places to update templates. The cost is worth paying when the client has private assets, regulated claims, active spend, or separate contractual obligations. For a one-hour brainstorming task with no connected tools and no private retrieval, a separate OS may be more process than value. ## Retrieval isolation: the place most client mixing starts The retrieval layer is the most common leak path because it is designed to find similar text. Similar text is exactly what agencies have. Campaign briefs, launch emails, landing page outlines, monthly reports, and customer research often share structure across clients. If the retrieval store can see everything, a model can receive the wrong source before it starts writing. There are two defensible patterns. The stricter pattern is one retrieval index or instance per client. Cloudflare AI Search documents an instance-per-tenant model for stronger isolation, where each tenant has separate storage and index resources. For an agency, that means Acme Dental’s documents live in Acme’s index, and Boreal Bikes’ documents live in Boreal’s index. A query from Acme has no path to Boreal chunks because Boreal chunks are not in that index. The second pattern is a shared store with server-side tenant enforcement. Snowflake Cortex Agents documents multi-tenancy using immutable session attributes with row access policies. Snowflake also frames this as shared responsibility. The platform provides tools. The customer must configure tenant boundaries correctly. For an agency, that means every table, view, retrieval source, and policy has to agree on tenant identity. Do not let the model choose the tenant filter. A tool signature like search_docs(query, client_id) is a warning sign if the model can fill client_id itself. The service layer should derive tenant scope from the authenticated session, workspace, or credential. The model can provide the query. It should not provide the boundary. A practical default is simple: use separate indexes for clients with private source material. Use shared storage only when you have server-side policies, tests for cross-client reads, and logs that show the applied tenant. The cost of separate indexes is duplicated setup and slower global administration. The cost of shared storage is that one wrong policy can become a cross-client leak. Retrieval should also return source metadata to the user. At minimum, the reviewer should see client name, document title, date, and source system for each citation or extracted fact. That visibility does not replace isolation. It gives humans a chance to catch stale files, wrong campaigns, and unexpected sources before a draft leaves the agency. ## Tool credentials must be tenant-scoped Tools need the same boundary as retrieval. If a client OS can access Google Drive, a CMS, a CRM, an analytics property, an ad account, a ticketing system, or a warehouse, the connector should be scoped to that client’s resources. The safe design is boring: Acme credentials can read Acme. Boreal credentials can read Boreal. No global agency token is handed to an agent unless the downstream system enforces the client boundary itself. AWS Prescriptive Guidance describes a pattern where tenant context flows to an MCP server, and the server uses that context to get tenant-scoped credentials for tenant-specific tools and knowledge. Google Cloud’s multi-tenant agentic AI architecture makes a similar distinction between tenant-specific local MCP servers and shared MCP servers. Local servers give firmer IAM boundaries and lower lateral risk. Shared servers reduce duplication but need strong identity propagation and authorization checks. For agencies, this choice shows up quickly. A local MCP server per client is easier to reason about during an audit. Each server has a small credential set and a small resource map. The cost is operational work: more servers, more updates, more secrets, more monitoring. A shared MCP server is easier to run at first. The cost is that every tool call must carry trustworthy identity, and every tool handler must enforce it. MCP authorization matters here. The MCP authorization specification says HTTP-based MCP authorization follows OAuth-style protected-resource behavior and that clients implement Resource Indicators so tokens specify the target resource. The practical agency question is narrow: is the token meant for this MCP server and this resource, and does the server reject tool calls outside the authenticated tenant? OAuth alone is not the answer. A bearer token can still be too broad. A consent screen can still grant access to a shared drive that contains multiple clients. A tool can still accept a model-supplied project ID. You need token scope, resource audience, server-side authorization, and a default deny path. The expected result is not a fancy agent. It is a boring error. When Acme OS tries to read Boreal’s CMS project, the tool should return an authorization failure. The model should not get a partial result. The logs should show the attempted tool, the authenticated user or service account, the workspace, and the denied resource. ## Human approval catches verbs, not data leaks Approval gates are not tenant isolation. They are a damage-control layer. They stop a wrong answer from becoming a client-facing action. In agency work, that matters because the expensive mistakes are usually verbs: publish, send, spend, delete, reset, invite, export, and change budget. Agentik’s public docs repeatedly describe human approval gates for work that publishes, sends, spends, resets, or wipes. That is the right category boundary. Let agents draft, compare, summarize, and prepare. Stop before they touch a live channel, a client audience, an account budget, or a destructive setting. The approval should be tied to the client OS and the role. A copywriter can request publication. The account lead approves. A paid media specialist can request a budget change. The budget owner approves. A researcher can attach new source material. A reviewer approves promotion into long-lived memory. The point is not to add a generic “Are you sure?” box. The point is to put the right person at the right gate. A useful approval screen shows what will happen, where it will happen, what source material was used, and which client boundary was active. For an email send, show the client, list, subject, sender, scheduled time, source docs, and final body. For a CMS update, show the project, page URL, diff, requester, and rollback path. For an ad budget change, show the account, campaign, old budget, new budget, effective time, and reason. Approval gates also help with memory. A draft should not become permanent client memory just because it was generated. Agencies change positioning often. Bad claims and old offers are easy to preserve by accident. Require approval before new facts, tone rules, offers, and claims move into long-lived memory. The tradeoff is speed. Approval gates slow down routine work. That is acceptable for external actions and persistent memory. It is less useful for low-risk internal drafts. Use gates where the blast radius is real. Do not bury every suggestion under the same approval modal, or the team will stop reading it. ## Checklist: boundaries, costs, and expected results Use this table as the operating checklist for a client OS. It separates workspace organization from enforceable security boundaries. The “expected result” column is the behavior you should see when the design is working. The artifact is intentionally plain. It is not a certification checklist. It is a way for an agency operator, technical lead, and account lead to sit in the same meeting and point at the boundary. If no one can name the boundary, the boundary probably lives in a prompt. ## Hypothetical example: Acme Dental and Boreal Bikes Hypothetical example: Northstar Growth serves Acme Dental and Boreal Bikes. Northstar creates one OS for each client. Acme Dental OS has a Director, strategist, researcher, copywriter, reviewer, and account lead. Its memory contains approved service descriptions, location pages, offers, tone rules, and prohibited claims. Boreal Bikes OS has the same role shape, but its memory contains product specs, dealer language, warranty caveats, seasonal campaign rules, and approved adventure language. At the workspace layer, the two clients are cleanly separated. Acme work happens inside Acme Dental OS. Boreal work happens inside Boreal Bikes OS. Each OS has its own approval gates before publishing, sending email, editing CMS pages, changing ad budgets, or promoting new facts into memory. That reduces the chance that a human opens the wrong brief or uses the wrong voice. At the security layer, Northstar gives each client a separate retrieval index. Acme’s campaign reports and source files are not stored in Boreal’s index. Boreal’s launch emails are not stored in Acme’s index. CMS credentials are separate. Acme OS can reach only Acme’s CMS project. Boreal OS can reach only Boreal’s project. The MCP server derives tenant scope from the authenticated session. The model never gets to pass client_id as a free argument. Now take the risky prompt: “Use last quarter’s best-performing launch email as inspiration for this week.” In a weak design, that prompt might retrieve a semantically similar launch email from the wrong client. Boreal’s product email could influence Acme’s dental promotion. The answer might sound good and still violate confidentiality. In the stronger design, the wrong file is not retrievable. Acme OS queries the Acme index. The CMS tool uses Acme credentials. The source panel shows Acme documents only. If the model tries to call Boreal resources, the tool returns an authorization failure and the event appears in the audit log. This example is hypothetical. It shows the architecture, not a claim that Northstar Growth exists or that Agentik implemented this exact setup for a customer. The point is the separation of duties: the OS organizes the work, and the storage, credentials, MCP server, and approval workflow enforce the boundary. ## Failure modes to name before they happen Failure modes need names because they recur. The first is prompt boundary drift. A user writes “stay inside Acme,” but the tool has access to every client. The model follows the prompt until retrieval returns a stronger pattern from another account. The fix is not a better instruction. The fix is a tool or retrieval scope that cannot see other clients. The second is metadata-only isolation. A shared vector store contains all clients, and the application adds client_id as a filter. That can be acceptable only if the filter is applied server-side and cannot be removed, changed, or guessed by the model. If the model composes the filter, you have a soft boundary. The third is global connector sprawl. An agency connects one all-access Drive, CMS, or ad platform credential because it is faster during setup. That creates a large blast radius. If the agent or user selects the wrong folder, account, or project, the connector may comply. Use client-scoped credentials or downstream access policies. The fourth is memory contamination. A generated draft, competitor note, or old offer gets saved into a shared memory and later appears as client truth. This can happen without any external data breach. It is still a client-quality failure. Require review before adding facts to long-lived memory, and keep memory per client. The fifth is approval theater. The approval screen says “Approve campaign” but does not show sources, target account, audience, budget, or destination. The approver cannot catch wrong-client actions because the needed facts are hidden. Approval needs enough context to be useful. The sixth is invisible denial. A tool blocks a cross-client request, but the event is not logged in a way the agency can review. You want failed access attempts in the audit trail. A denial can show a misconfigured OS, a bad prompt pattern, or an overly broad agent plan. These failures are not exotic. They are the ordinary result of giving a language model tools that were designed for humans with broad agency permissions. The fix is to move the client boundary out of natural language and into systems that already know how to deny access. ## Where Agentik fits, based on public docs Agentik fits this pattern at the operating layer. Its public docs describe an OS installed into an MCP-capable host that the customer already uses. They describe named jobs, a Director lead agent, shared or longer-lived memory, tool permissions, MCP server access, OAuth, and human approval gates for work that publishes, sends, spends, resets, or wipes. Those are useful primitives for an agency that wants one operating context per client. The honest boundary is equally important. The public Agentik source reviewed for this article does not document per-client tenant isolation guarantees, separate databases per client, cryptographic isolation, SOC controls, or legal compliance outcomes for agency multi-client use. So do not treat “create a client OS” as the whole security design. Treat it as the top layer of the design. A good Agentik-style agency setup would create a client OS for each account, define named roles, attach only the client’s tools, keep client memory separate, and require approvals for external or destructive actions. Then the agency’s underlying systems would enforce the rest: separate retrieval indexes or row policies, scoped OAuth grants, MCP authorization, and audit logs. The host matters too. Agentik’s docs say the OS runs inside an MCP-capable host that the customer already uses, and the host runs the model and pays token costs. That means the agency should also understand the host’s workspace model, file access, logging, and connector permissions. A client OS inside a permissive host still depends on the host’s controls. This is not a pitch to put every client process into agents. Some client work should remain manual. Legal review, high-risk regulated claims, crisis communication, and large budget changes may use AI for drafting or summarizing, but the decision path should stay human-owned. The OS can prepare the packet. It should not become the accountable party. ## What this approach does not solve Do not use one OS per client as your only control when contracts require strict data separation, regulated data is involved, or the client expects proof of isolation. In those cases, ask for architecture documentation, access-control evidence, data-flow diagrams, audit logs, and the exact storage and credential model. If you cannot get those, say you do not know. Do not use a shared retrieval index for sensitive client materials unless you can prove server-side tenant enforcement. Snowflake’s Cortex Agents multi-tenancy docs show a shared pattern using immutable session attributes and row access policies, but they also make the configuration responsibility explicit. Shared can be safe. Misconfigured shared is dangerous. Do not attach a global agency credential to a client OS for convenience. If the credential can read every client, the agent has a path to every client unless another layer blocks it. The connector should be scoped, or the downstream service should enforce the boundary with IAM, policy, or row-level access. Do not depend on approval gates to catch hidden source leaks. An approver can review a draft and still miss that a sentence came from the wrong client. Approval gates are for actions and persistent changes. Retrieval and tool isolation have to prevent the wrong source from entering the context in the first place. Do not overbuild for low-risk work. If a strategist is brainstorming public social hooks with no client files, no memory writes, and no connected tools, a lightweight workspace may be fine. The moment you attach private files, client credentials, persistent memory, or publishing actions, the boundary needs to be real. The useful rule is blunt: if the agent can read, write, publish, spend, or remember on behalf of a client, that client deserves its own operating context and an enforceable resource boundary. If it can only draft against public information, the OS boundary is mainly a workflow choice. ## Agency client OS isolation checklist with costs, boundaries, and expected results. | Control | Cost | Boundary it protects | Expected result | | --- | --- | --- | --- | | One OS or workspace per client | Setup time for each account, more templates to maintain, more places to update roles | Client brief, role list, memory, approval workflow, and attached tools | A user can tell which client context is active before work starts, and drafts follow the right brand and approval path | | Separate retrieval index or instance per client | Duplicated indexes, per-client ingestion jobs, more operational overhead | Client documents and embeddings | A query from Client A cannot retrieve Client B documents because they are not in the same index | | Shared retrieval with server-side tenant policy | Policy design, testing burden, risk of misconfiguration | Rows, tables, views, and retrieval results filtered by immutable tenant context | The service applies the tenant filter before generation, and the model cannot change or omit it | | Tenant-scoped OAuth and tool credentials | More credentials to issue, rotate, monitor, and revoke | Drive, CMS, CRM, analytics, ads, warehouse, and project-management tools | A tool call from Client A fails when it targets Client B resources, even if the prompt asks for them | | MCP server derives tenant from session, not model input | More server logic and audit fields, less flexible ad hoc tooling | Tool handlers and authorization checks | The model supplies the task query, while the server supplies tenant scope and rejects cross-tenant calls | | Human approval before publish, send, spend, reset, wipe, or memory promotion | Slower external actions, reviewer workload | Live channels, budgets, destructive actions, and long-lived memory | A named human sees the target client, destination, sources, and change before the action runs | | Audit logs for allowed and denied tool calls | Storage, review process, log access controls | User, agent, workspace, tool, resource, decision, and timestamp | The agency can reconstruct who or what accessed a client resource, and failed cross-client attempts are visible | ## Sources - [Agentik public docs, llms-full.txt](https://agentik-os.com/llms-full.txt) - [AWS Prescriptive Guidance, Enforcing tenant isolation in agentic AI](https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-multitenant/enforcing-tenant-isolation.html) - [Google Cloud Architecture Center, Multi-tenant agentic AI system](https://docs.cloud.google.com/architecture/multi-tenant-agentic-ai-system) - [Cloudflare AI Search, Multitenancy](https://developers.cloudflare.com/ai-search/how-to/per-tenant-search/) - [Snowflake docs, Multi-tenancy for Cortex Agents](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-agents-multi-tenancy) - [Model Context Protocol authorization specification](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/basic/authorization/index.mdx?utm_source=openai) - [VS Code docs, Agent harnesses](https://code.visualstudio.com/docs/agents/run/agent-harnesses) ## FAQ ### Can an agency run one AI OS per client and call that tenant isolation? No. One OS per client is a good operating pattern, but tenant isolation needs controls below the workspace: scoped credentials, storage boundaries, access policies, and audit logs. ### Should each client get a separate vector index? Use a separate index or instance when client data is sensitive or contractual separation matters. A shared index can work only if tenant filters are enforced server-side and cannot be changed by the model. ### Can MCP keep agency client data separated? MCP can carry identity and authorization context, but the server still has to enforce it. The important question is whether the tool derives tenant scope from the authenticated session, not from a model-supplied client_id. ### Where do approval gates fit? Approval gates do not isolate data. They limit damage before a draft is published, an email is sent, a budget is changed, or a client system is reset. ### When is one OS per client too heavy? It is too heavy for short internal experiments, non-client research, or work that does not touch private assets. Use a lighter workspace only when no client credentials, memories, or retrieval stores are attached. # The return is the hour you can point to URL: https://agentik-os.com/blog/return-without-invented-numbers Published: 2026-09-20; updated: 2026-09-20 A return that cannot be traced to a clock, a rejected draft, or a number the company already keeps is not a return. It is a slide. This essay is the method, not a promise. ## Three things that count, and one that does not Time counts when a person can name the task they no longer redo. A weekly report assembled from the same five sources. A first draft of a campaign that used to start from a blank page. A handoff that used to be a meeting because the context was not written down. If you cannot name the task, you cannot claim the hour. Avoided mistakes count when a gate stopped a sentence the company is not allowed to say. That is not a vibe. It is a draft that was not published. Keep the draft. The human gate in the operating system is the record. Revenue counts only if the company already measures that revenue without the operating system. An operating system does not create a new accounting category. If pipeline, retention, or cycle time is already on a dashboard, you may ask whether the system moved it. If it is not on a dashboard, do not invent the movement. What does not count is a borrowed percentage. "Companies like yours save forty percent" is not evidence. Agentik does not publish that number because it does not have your clock. Neither should a vendor slide. ## Orchestration is how the hour gets saved more than once One agent saves an hour once, if the prompt was good. An operating system saves the next hour because the decision, the voice, and the refusal are still there on Monday. That is orchestration: a director, specialist agents, shared memory, and a person who can say no. It is not a swarm for its own sake. The impact in a company is usually sequence, not magic. The content agent drafts inside the voice. The growth agent refuses a channel the brief did not allow. The librarian agent finds the last decision instead of asking the team to remember it. Each handoff that does not become a meeting is the return. Link those handoffs to the operating systems you can actually install: Content, Growth, Librarian. Decision is retired. The host still pays the model. Claude, Claude Code, Cursor, ChatGPT, Codex, or Hermes. Agentik does not buy the tokens, so the return calculation must not pretend the model was free. Put the host bill next to the hours. If the hours do not cover the bill, say so. That is a useful result. ## Write the return as a before and after you can audit Before: who did the task, how long it took last time, where the source files were. After: who approved it, how long the approval took, what the system was not allowed to do. One paragraph each. If you need a spreadsheet, use the company's, not a template from the internet. On-demand work at Agentik is priced on that gap, not on a day rate published on the site. There is no public price list for the service, and this essay will not invent one. Marketplace plans are a different thing: a lifetime seat, or a monthly seat, for official operating systems. Those prices are on the pricing page. Do not mix them into a services ROI story. A company that is not AI-native should run this method on one workflow before it runs it on the firm. One workflow with a named approver and a written voice is enough to see whether the hour is real. The thirty-sixty-ninety plan is that sequence. It is not a transformation programme. Stop when the hour is visible. Do not scale the story past the workflow you measured. ## The call is where the baseline gets said out loud A public page cannot know your baseline. The call can, if you bring one workflow and the last time you did it. Who touched it. How long the approval sat. Which sentence you are not allowed to publish. That is the brief. The connection work comes after, and only for the tools that workflow actually opens. A gap analysis that starts from the vendor catalogue, instead of from the workflow, will recommend software. It will not find the missing fact. Impact in the enterprise, when it is real, shows up as a handoff that got shorter and a mistake that did not ship. Orchestration is what keeps that handoff short the following week: the director still has the rule, the specialist still has the voice, the approver still has the gate. If any of those reset to a blank chat, you did not buy an operating system. You rented a conversation. Keep the write-up next to the work. Link it to the readiness checklist before you install, and to the fractional method if you want a person to run the audit with you. Neither document contains a percentage you can paste into a board deck. If the board wants a percentage, it has to come from the baseline you brought. A glossary term will not supply it either. Agentik's public position stays the same while you do this. The operative system runs on the host you pay. Tokens are not included. Official systems you can install today are Content, Growth, and Librarian. The service around them is on demand, and it does not have a price list on this site. Do not let a generated article invent one. This job will not. The comparison page says where Agentik sits and where it does not. Use it if someone asks you to score a chatbot against an operating system. The answer is not a ranking. It is a different job. ## Throw out the slide you cannot audit You already know the slide. A vendor, sometimes a colleague who means well, puts a percentage on it. Time saved. Tickets deflected. Pipeline lifted. The number is round, the logo is tasteful, and nobody in the room did the task. Ask one question: whose clock? If the answer is "companies like yours", the slide is fiction. Put it in the bin before it becomes a target your team has to pretend to hit. The replacement is uglier and much more useful. One workflow. The last three times you ran it. Who touched it, how long the ugly middle took, what got sent back. You do not need a research department for that. You need the person who did the work and a calendar they trust. If they cannot remember, that forgetfulness is itself the finding. Do not fill it with an industry average. An average from someone else's firm is not a baseline. It is a costume. Finance will ask for a payback. Give them the host bill and the hours you can name, and say what you cannot name yet. That sentence is allowed to be incomplete. A complete sentence with a borrowed number is the thing that gets you in trouble in the QBR, not the incomplete one. Better to walk into that meeting with a short table and a blank cell than with a percentage nobody can point at. ## Stay on one workflow until the hour is boring The temptation, once a draft comes back faster, is to announce a programme. Don't. Run the same workflow until the saving is dull. Dull means you can predict it. The voice note is there. The approver knows what they are checking. The refusal, when it happens, is about the rule and not about a surprise. If it still feels like a demo, you are watching a good prompt, not an operating system. Orchestration is what makes the second week look like the first. The director still has the assignment. The specialist still has the voice. The memory still has Friday's no. Skip any of those and Monday is a new chat with a confident tone. That is the failure mode people describe as "we tried AI and it didn't stick". It stuck. It stuck to a tab that closed. Put the host invoice next to the scrap of hours before you tell anyone it worked. Claude, Claude Code, Cursor, ChatGPT, Codex, Hermes: whichever one you already pay. Agentik does not buy those tokens, so a return story that treats the model as free is cooking the books. If the invoice is larger than the hours, write that down too. A negative result on one workflow is a successful measurement. It tells you not to scale the story. The thirty-sixty-ninety page is this patience in calendar form. It is not a transformation. Stop when the hour is visible on one line of work. The use-case page shows Content, Growth, and Librarian as those lines, plus the gap that does not fit them. It does not show a customer logo, because this site does not invent customers, and neither should your deck. ## FAQ ### Do you guarantee a return? No. The method tells you how to notice one. A guarantee would require your numbers, which this page does not have. ### Where do the marketplace prices live? On the pricing page, in USD. They are not a services rate, and they do not include model tokens. # Orchestration is the operating system, not a bigger chat URL: https://agentik-os.com/blog/orchestration-is-the-operating-system Published: 2026-09-18; updated: 2026-09-18 A pile of agents is still a pile. An operating system is the agreement about who drafts, who remembers, who is allowed to act, and who must approve. That agreement is the product. ## A chat forgets the company on purpose A chat is a good instrument for a question that dies when the tab closes. An operating system is for the question that must be answered the same way next month. The difference is not the size of the model. It is whether the last approval, the forbidden claim, and the owner of the work are still in the room when the next person asks. Orchestration is the dull part that makes the impressive part safe. A director assigns. A specialist drafts. Memory holds the decision. A person approves anything that leaves the building. Skip any of those and you have a demo. The essay on the human gate is the approval half of this sentence. Install is through the Model Context Protocol, on the host you already pay. The operating system does not bring its own model bill. If a diagram shows Agentik paying OpenAI or Anthropic for your work, the diagram is wrong. The host invoice is the model cost. Keep it beside the hour you saved. That difference is the whole point of the bill. ## Orchestrate the work you already repeat Start from a workflow with a name. Publish a page. Answer a lead. File a decision. If the workflow has no name, you are not ready to orchestrate it. You are ready to watch someone do it once and write down the steps. That write-up is the context the agents will share. Content OS is that pattern for words the brand is allowed to say. Growth OS is that pattern for the motion around a launch. Librarian OS is that pattern for finding the decision again. They are examples you can install, not a claim that every company needs all three on day one. The marketplace lets a member choose. Companies that are not AI-native often try to orchestrate the whole firm in a workshop. The gap analysis says otherwise. One missing fact blocks the workflow. Find that fact. Write it down. Then let the director refuse jobs that arrive without it. Refusal is a feature. A system that always produces a draft is not orchestrated. It is eager. ## Impact is a changed handoff Look at the handoff, not the transcript. Did the specialist receive the voice note, or did a person paste it again? Did the approver see the rule the draft followed, or did they re-read the whole brief? Did the next week start from the stored decision? Those are the impacts an operating system can actually have. They are visible in a calendar and a folder. They are not a forecast. A forecast needs the company's baseline. This site will not supply a baseline you did not measure. Use the return essay for the method, and the readiness checklist for the facts to gather before you install anything. When the handoff is still a meeting, the orchestration is not done. Add memory or add a gate. Do not add another agent to watch the meeting. Another agent is how piles form. ## Orchestration fails where the context is still missing A director cannot assign a job it cannot describe. If the company has not written the voice, the forbidden claim, or the approver, the operating system should stop. That stop is the context gap, made visible. Companies that are not AI-native hit this stop immediately, and that is useful. It is cheaper than a month of plausible drafts nobody can sign. The return, again, is not a number this page owns. It is the meeting you did not hold because the decision was already stored, and the draft you did not ship because the gate fired. Put those next to the host's model bill. If the bill is larger than the meetings, the orchestration is not paying for itself yet. Say that in the review. Do not hide it under a metaphor. Read the context-gap essay before you add a fourth agent. Read the return essay before you report upstairs. Read how to add a remote MCP server before you install anything on a host. Those three pages are the mesh. This one is the definition they assume: orchestration is the agreement, and the agreement is the system. The glossary defines the words if a term in that mesh is still loose: operating system, human in the loop, model context protocol. Nothing here replaces an employee. The gate is a person. The brief is a person. The operating system is how those people stop repeating themselves to a machine that would otherwise forget them by design. Install order, if you want one that does not skip the gap: write the rule, name the approver, connect only the tool that workflow uses, then ask the director to run one job and refuse the next job that arrives without the rule. That is a week of work for a single workflow, not a programme. The use-case page shows Content, Growth, and Librarian in that spirit, plus the on-demand gap. It does not show a customer logo, because this site does not invent customers. MCP is the pipe. It is not the memory and it is not the gate. Adding a remote server, which the install essay describes, lets the host see the tools. It does not decide which tool is allowed to speak for the brand. That decision stays in the operating system, and the person at the gate still signs it. If a pitch says the protocol replaces the approver, the pitch has mixed up the layers. ## What a week looks like when it is actually orchestrated Monday is a job with a name. Not "help me with marketing". "Draft the launch note for the feature that shipped Friday, in the voice note, and stop if the forbidden-claims list is missing." The director either assigns that or refuses it. Refusal before noon is a good Monday. It means the system noticed the hole while the hole was still cheap. Tuesday the specialist drafts, and the draft arrives with the rule it followed, not with a tour of its reasoning. The approver should be able to check the sentence against the list in one sitting. If they have to reconstruct the brief from memory, the handoff failed, even if the prose is lovely. Send it back. Do not add an agent to summarise the brief the approver already should have been given. By Thursday you either have a stored decision or you have a meeting. Prefer the decision. Write what was approved, what was cut, and who signed. Next Monday that note is the start of the job, not a search. If you cannot find it in under a minute, Librarian's whole point just failed in miniature, and you do not need a second tool. You need the note in a place the next run opens by default. Friday is the only retrospective that matters. Did anyone paste context that should have been in memory? Did the gate fire, or did a person silently fix a sentence the system was never told to avoid? Those two questions are the impact review. They fit in a short message. They do not need a dashboard, and they do not need a percentage to be worth keeping. ## A cast is not a system Naming five agents feels like architecture. It is a cast list. The system is the agreement between them: what the director may assign, what the specialist may assume, what memory must hold, what a person must still sign. If that agreement is a diagram and not a rule the next job can trip over, you have a poster. Posters do not refuse work. This is why another chatbot does not close a context gap. The chatbot can be brilliant in the tab. The gap is the fact that was never written down, and a new tab does not write it down either. Orchestration starts the moment a missing fact can stop the job. Before that moment you are still chatting, however many names are on the slide. Companies that are not AI-native are often sold the cast first, because the cast demos well. Take the opposite order. One job. One missing fact, written down. One refusal you can show a colleague. Then a second specialist, if the first handoff is actually shorter. The marketplace will still be there. Content, Growth, and Librarian are installable when the agreement exists, not before, and a lifetime seat is not a substitute for the agreement. Nothing in that week replaces the person at the gate. If a vendor tells you the system can sign, they are selling a different product, and it is not this one. The host still pays the model. The pipe is still MCP. The memory is still only as good as the note you bothered to store. That is the whole machine. It is enough, if you let it be dull. ## FAQ ### Is multi-agent the same as an operating system? No. Multi-agent is a cast. An operating system is the cast plus shared memory, permissions, and a human gate. ### Which host runs it? Claude, Claude Code, Cursor, ChatGPT, Codex, or Hermes, through MCP. The host you pay is the host that runs the model. # Context gaps show up before the agents do URL: https://agentik-os.com/blog/context-gaps-before-agents Published: 2026-09-18; updated: 2026-09-18 An agent that cannot see the brief, the brand, the approval, or the last decision will improvise. That improvisation is the gap. Closing it is the work, before anyone asks the model to be autonomous. ## A context gap is a missing fact the system is expected to know A company that is not AI-native still runs on inboxes, slide decks, and the memory of the person who was in the room. None of that is a defect. It is the current operating record. An agent dropped on top of it inherits the holes. If the brand voice lives in one person's head, the agent does not have a brand voice. If the approval rule is "ask Sarah", the agent does not have a gate. It has a name. The useful question is not whether the model is clever. It is which facts the next piece of work needs, and which of those facts are written down where a system can read them. A context gap is any required fact that is absent, stale, contradictory, or trapped in a tool the operating system is not allowed to open. This is why a chatbot demo and an operating system diverge in the second week. The demo answers from the prompt. The operating system has to answer from the company. See what an AI operating system is for the contract: shared memory, a human gate, and skills the host already runs. ## The usual holes are not in the model Ownership goes first, and it is almost never written down. Ask who may approve a public sentence, a price change, or a note that leaves the building. If the answer is a vibe, or a first name with no backup, an agent that "just sends" is not a feature. The human gate is that name, made durable. It is not a delay someone added to look careful. Then the memory of decisions. Teams redo work because the last answer lived in a thread that scrolled away. An operating system is supposed to keep the decision next to the work, so the next run reads it. If that record does not exist, the first job is to write the decision in a place both a colleague and an agent can open. Hiring another agent before that file exists just creates a faster way to guess. Tool access is the hole people notice, and the one they over-trust. Marketing in one suite, support in another, the numbers in a third. A connection that can see a calendar and still cannot see which campaign is allowed to speak is an open pipe. It feels like progress because a logo lit up. The on-demand method starts with an audit and a brief for this reason: the logo is not the fact. ## Name the gap in a sentence a colleague can check A gap worth fixing can be stated without a model. "We cannot tell, from the files we have, which claims are allowed on the site." "We cannot tell which leads were already refused." "We cannot tell who must approve a discount." If the sentence needs a benchmark, a percentage, or a vendor score to sound serious, it is not a gap yet. It is a wish. Write the sentence, then write the smallest artifact that would make it false. A one-page voice note. A list of forbidden claims. A named approver. Those artifacts are the context. Agents come after, because an agent without them will fill the blank with something plausible. Companies that are not AI-native are not behind. They are unpublished. The operating system is the place those sentences get stored, versioned, and handed to the host the company already pays. Agentik does not buy the tokens. The host does. The gap work is still the company's. ## What changes when the gap is closed The team stops re-explaining the company at the start of every chat. The director agent can refuse a job that is missing a required fact, instead of producing a confident wrong draft. Approvals get shorter because the draft already followed the written rule. None of that is a guaranteed return. It is the mechanism. The return, if it comes, is time not spent reconstructing context, and mistakes not shipped. Measure that in the company's own units: hours the team can point to, drafts sent back, decisions that did not have to be remade. Do not import a case study from another firm. If you cannot point to the hour, you do not have the return yet. The services page says the same thing: money follows the gap you can prove, not a rate card. Read next: the readiness checklist, the human gate, and the thirty-sixty-ninety implementation plan. They are the same argument in operational form. ## Leave alone the work that has no repeated fact Not every blank is a gap the operating system should close. A one-off negotiation, a private conversation, a decision that depends on a room you cannot record: those stay with people. Automating them creates a file that looks like context and is actually a leak. The audit should say "do not connect this" as often as it says "connect this". A company becomes more AI-native by publishing the facts it is willing to reuse, not by connecting every tool it owns. The librarian pattern is the test. If a colleague cannot find the decision a month later, the agent will not find it either. Write the decision in a place both can open. Then, and only then, point an agent at it. The vision is modest on purpose. Operative systems are how a firm keeps its own rules next to the work, and how a director can refuse a job that arrives without those rules. The impact is fewer reconstructed mornings. The return is whatever those mornings were worth on your clock, not on a chart from a conference. ## Watch one Monday before you add another agent Sit with the person who opens the file, not the person who sponsors the project. Ask them to do last week's task again, slowly, and write down every time they leave the page. A sentence from a deck. A number from a chat. A name they have to ask out loud. Those exits are the gaps. They are dull, and they are the map. This usually takes less than an hour and tells you more than a workshop. The model is not confused. The company is unpublished. A claim the legal team already killed is still living in a slide nobody dated. The person at the desk knows not to repeat it. The agent does not, because that knowledge never became a file. Write the gap as a missing object. "The list of claims we will not make is not a file." "Nobody is named to approve a discount past the usual band." "The refusal of this lead is in a thread the new hire cannot open." If you cannot point at the object, you are still describing a mood. Do not connect a tool to a mood. Bring that page to the call if you want the on-demand pass. One workflow, the exits, the missing object. The audit is supposed to start there. A catalogue of agents is a later conversation, and often a shorter one than people expect, because half the exits close when someone finally writes the rule down. ## An agent receives the file, not the room People underestimate this because they were in the room. They hear "send the update" and they already know which update, which client, which sentence was argued last Tuesday. The agent hears the words on the screen. Shared memory only helps if Tuesday was written into it. Otherwise the director is assigning a job with a hole in the middle, and a capable model will plaster the hole with something that sounds like your company. That plaster is the expensive failure. It does not look like an error. It looks like a draft you could almost send. The human gate exists for that draft. It is slower than people want, and it is still cheaper than the correction after a customer sees it. If the gate is "ask Sarah" and Sarah is on a plane, you do not have a gate. You have a hope. Orchestration does not fix a missing fact by adding a second agent to look for it. The second agent searches the same empty shelf. The useful move is to stop the job. A director that can say "this brief has no approver, I will not draft" is doing the operating system's actual work. A director that always returns a paragraph is a chatbot with a job title. Companies that are not AI-native hit this stop on the first real workflow, and they should. It is information. The readiness checklist is the same test in list form: which facts are written, who signs, which tool is allowed to speak. If those three are blank, install is theatre. Read that checklist before you read a host guide. ## After the file exists, the mornings change shape The change is small enough to miss if you are waiting for a transformation story. Monday's draft starts from the voice note instead of from a blank box. The approver reads a diff against the rule, not the whole history. The next person does not get a tour of the company's anxieties. None of this shows up as a percentage I am willing to print. It shows up as a meeting that did not get booked. Keep a scrap of paper for a month. Each time someone pastes context into a chat that the system should already have held, mark it. Each time the gate sends a draft back because the rule was missing, mark that too. At the end of the month you have a count that belongs to you. That count is the only return this subject can honestly claim. The essay on the hour you can point to is the method for writing it up without borrowing a slide. Leave the private rooms alone while you do this. A negotiation, a personnel note, a conversation that was never meant to be a record: connecting those is not a gap closing. It is a leak with a schema. The librarian pattern is the adult test. If a colleague should not be able to find it, the agent should not either. Then, and only then, point a specialist at the file. Content if the file is what the brand may say. Growth if the file is which motion is allowed. Librarian if the file is the decision you need again next month. One of those, on one workflow, is a serious start. All three on a Tuesday because a diagram looked complete is how piles of agents get their reputation. ## FAQ ### Is a company that is not AI-native broken? No. It has not written down the facts an operating system would need. That is a documentation and access problem, not a moral one. ### Can an agent discover the gaps by itself? It can notice when a required fact is missing, if you told it the fact was required. It cannot invent the company's rule and be right.