What changed

Before this release, one agent held every tool the platform had, and the tool list grew every time an app added to it. That does not scale: a model choosing between hundreds of tools chooses badly, and every turn pays for the whole catalogue whether it needs it or not.

The framework now splits the job in two. A root agent — the Kademi Copilot — holds almost no tools of its own. Its skill is knowing which specialist owns the request. Eleven specialists each own one area of the platform and hold the tools and the domain knowledge for it. The root states the task in full, hands it over, and assembles what comes back.

Three things follow from that split, and they are the substance of the release:

• A specialist sees one scoped task and none of the conversation, so neither the conversation nor the root's planning context grows as the tool library grows.
• Each agent can be tuned on its own terms — which class of model it runs on, how hard it thinks, how much work it may do — because routing and domain work are no longer the same job.
• A run is now a persisted, resumable object rather than a recursive loop in a script, so it can pause for a human decision and pick up later.

Everything an administrator can see or change lives under AI Agents in the admin menu: Agents Designer, Agent Manager and Web Access.

The eleven specialists

The full roster is supplied by the agents-lib library and appears in every account. The Copilot is the root; the rest are specialists it delegates to. An account can add its own alongside them.

How a turn runs

Every run goes through four phases in order. This replaced a flat recursive tool-calling loop whose only guard was a hard-coded twenty-call cap. Any phase can be skipped or can break the run.

Plan and Verify are root-only in practice. A specialist does not plan — the root does that and hands over a settled task — and its Verify makes no model call. So a specialist's tuning is about its Act phase.

Models, thinking, budgets

Three knobs control what a run costs and how capable it is. Each resolves the same way: what the run explicitly asks for, then the agent's own setting, then the platform default.

Model tier — which class of model, not which model

An agent names a tier, and the platform resolves it to the best model in that tier the account actually has enabled. This is the recommended setting: an agent on a tier follows model upgrades without anyone editing it. Pinning an exact model is possible but overrides the tier and freezes the agent on that model as newer ones arrive.

Thinking — reasoning effort

Three levels: Low for obvious next steps, Medium, and High for work where the next step depends on the last answer. Raising it on a run raises it for the specialists that run delegates to, which is where the work actually happens.

Budget — how much work a run may do

A run has resolved ceilings, frozen when it is created so that editing a definition mid-run cannot change the contract an in-flight run is held to. The standard allowance is sized for someone watching a spinner:

When a run stops on a ceiling it says which ceiling, so an operator can tell "hit the tool-call limit" from "the model stopped on its own".

Where definitions come from

This is the concept most likely to confuse a reader, and it has visible consequences, so it is worth its own page in the documentation.

Agent definitions are supplied by apps, not copied into every account. An account running the stock Copilot is reading the app's definition, so it improves whenever the app is updated. Three states are possible, and the Designer labels each one:

Following the app	The default. No local copy exists. The agent improves as the app is updated. There is nothing to reset and nothing to delete, because the app supplies it.
Overridden	Somebody saved a change, which took a local copy, and that copy now wins. It has stopped tracking the app: a new function, a corrected instruction or a flag routing the agent through newer code has not reached it and will not. Reset to app defaults discards the copy and follows the app again.
Superseded copy	An older local copy, saved for a previous version of the framework in which the agent worked differently, so it is deliberately not applied. The app's definition is what runs. The old copy is still stored and readable through Edit XML file.

An account's own definitions are XML files in the queries repository, under agents/. The Edit XML file button on any definition opens that file directly, which is the only way to reach settings the form does not expose — attributes, an exact model pin, and skills.

Configuring an agent

Opening a definition gives seven tabs. They are not a sequence — each is an independent facet of the same agent.

Basic Information

Identity, instructions, and how this agent fits into the team.

Functions — what the agent can actually do

An agent can do nothing until it has functions. The left column is what this agent holds; selecting one shows what it does, the roles it requires, and each parameter.

The catalogue is contributed by apps. Around twenty-five installed apps and libraries register tools, and a new app adds its own the moment it is installed — the agent framework needed no change to pick them up.

Groups — who may use this agent

Groups decide which users can launch an agent from this definition. They are also the gate on delegation: an agent may only hand work to a specialist whose groups include the agent's owner.

Skills — reference documents read on demand

A skill is a document the agent reads only when the task calls for it: a cookbook, a house style, the steps of an occasional procedure. Only its name, purpose and keywords sit in the instructions on every turn, so a long skill costs nothing on turns that do not need it. A skill marked always read is put in front of the agent in full instead.

An account adds its own skills by creating  agents/skills/  in the queries repository with a   root. Those are added to the app's, and a skill reusing an app skill's name replaces it.

Timers and Events — running without being asked

Covered in section 08, along with the run-tuning controls that live on an event handler.

Memory

Covered in section Memory.

Definitions vs agents

A definition is a template. An agent is one running instance of that template, owned by one person. This distinction carries the entire security model, so it is worth being explicit about in the documentation.

Agents are started from this page. Three modes:

• Yourself — one agent, owned by the current user.
• Agent Definition Groups — start one for every profile matching the groups on the definition. This is the bulk rollout.
• Specify Profile — pick one person and start an agent for them.

Opening a single agent shows its timers with their next fire time, a way to test a timer immediately, and any workflows it is running.

Four ways a run starts

Chat is the visible one, but three others run unattended, and they are where the framework earns its keep.

Timers

Events, and the buffering that makes them affordable

Every run is an AI call, so binding an agent to a frequently-firing event naively would be a model call per event forever. Instead, matching events are collected, and the agent runs once over the batch when either threshold is reached — this many events, or this many seconds. One event is right for something rare and worth answering on its own; a larger batch for something frequent.

An event handler is also where the run-tuning controls surface in the UI. Because nobody is waiting on an event-driven run, it can afford to think harder and dig further than a chat turn. All three settings reach the specialists the agent delegates to, not just the agent itself.

The Copilot panel

The panel opens on the right of any admin page and is resizable. A conversation belongs to the agent it was started with, for its lifetime — you cannot move a conversation between agents.

When a conversation grows past the threshold the meter names, it is compacted rather than truncated: the canonical history is append-only and untouched, and a marker lets the model-facing view be recomputed on demand. Conversations are titled automatically in the background a few seconds after they start.

The panel also accepts image and PDF attachments, and renders charts and generated documents inline.

Consent

An agent that can change things has to ask before it does, and the framework has a first-class mechanism for that. A tool marked as requiring consent stops the run, states plainly what is about to happen, and waits.

Two properties are worth spelling out for readers:

• The prompt states consequences, not just the action. Destructive tools are written to say what the user is about to lose, and the framework renders them differently from ordinary confirmations.
• A pause can outlast the session. Because a run is a persisted object, a consent pause can span an asynchronous channel — an email or SMS reply that takes hours or days — and the run resumes where it stopped rather than starting again.

Consent is applied by judgement, not blanket policy. The Developer agent's writeRepoFile deliberately does not prompt, because a loop that asks on every file write is one nobody would use; deleteRepoFile and revertBranch do. Every write instead returns the hash the branch was on immediately before it, so the undo exists whether or not anyone thought ahead.

Memory

Agents remember the person they work for between conversations. What has been recorded is put in front of the agent at the start of each new conversation, so it does not ask the same question twice.

There are two kinds of memory, and the difference is about whose fact it is:

Remembering is the root agent's job alone. Specialists see one scoped task and none of the conversation, which is the worst position from which to judge what is durably true about a person — and every specialist writing into the same store would fill it with domain trivia.

Web access

Agents can read web pages, but only from hosts the account has explicitly allowed. The list starts empty, which means an account that has configured nothing has agents that cannot read any web page at all.

The constraints are worth restating verbatim in the documentation, because they answer the questions a security reviewer will ask:

• Agents can only read. They fetch the page, convert it to text, and use it. They never sign in, submit a form or post anything.
• Requests are anonymous, so a page behind a login returns whatever a signed-out visitor sees.
• robots.txt is respected, and a redirect off an allowed host is refused.

The security model

One invariant carries everything, and it did not change in this release:

Four mechanisms enforce it, and each answers a different question a reader will have:

Function roles	Every function declares the roles it requires. A user without them is never offered the tool — and the check is repeated when the tool actually runs, not only when it is offered, so a model that invents a tool name gets nowher
The agent's whitelist	An agent can only call functions its definition lists. Holding the role is not enough if the agent was never given the tool.
Group membership	Decides who may launch an agent from a definition at all, and gates delegation: an agent may only hand work to a specialist whose groups include the owner.
Consent	For actions worth a human decision regardless of permission — see section 10.

 Two boundaries are deliberately not drawn, and both are choices rather than gaps. There is no restriction confining the Developer agent's writes to a non-live branch, because most accounts develop directly on the live version and such a rule would only make the tools unusable — instead every write reports whether it was live and returns its own undo. And there is no new messaging-channel abstraction: Slack, email, SMS and web chat remain self-registering marketplace apps, which is what lets a channel own its own protocol.

Notes for the docs team

The four ideas a reader needs first

1. A definition is a template; an agent is one person's instance of it. Nearly every other question resolves once this is clear.
2. The Copilot delegates; it does not answer. The "Asking …" progress line (Fig 15) is the fastest way to teach this.
3. Saving a change forks the agent from the app. Worth a callout wherever the Designer is documented.
4. An agent is its owner. The answer to almost every "can it see / can it do" question.

Two things seen on screen that look like defects

Both were captured in these screenshots and should be checked against the current build before anything is published around them.

• The delete-group consent prompt (Fig 18) names the group by its id — "the group 16" — rather than its title, which undercuts the point of a prompt that exists to be read.
• An agent created with no title is displayed as "nulls agent" on the agent detail page (Fig 10).

Areas this briefing does not cover

• Agent workflows — the multi-step model referenced on the agent page. Only lightly exercised here.
• The Developer agent's write path in depth. It has its own surface area — repository writes, mandatory load-checks after every write, atomic revert — and probably deserves its own document aimed at client developers rather than administrators.
• MCP. The same tool library is reachable from external MCP clients through the KMCP app, which is how an agent outside Kademi can use these tools. Separate app, separate documentation.
• Messaging channels. Slack, email and SMS as agent surfaces are unchanged by this release and are documented with their own apps.

Source material

The design document behind this work is feature-plans/AGENTIC_FRAMEWORK_UPGRADE_PLAN.md in the repository, and the build notes and QA testing notes on issue #24134 are the most reliable record of what each increment actually changed.