Set up agents.
An agent is a saved setup for a particular kind of work. Choose what it should help with, which AI it uses, and which tools need your approval. An administrator creates agents; other users choose one to start a conversation.
Set up an agent for a job
Give it a name, describe what it should help with, and choose an AI. You can add instructions and choose its tone. These guide how it responds; access to services and actions is controlled separately.
- Administrators create and update agents.
- Other users choose an agent when they start a conversation.
- Optional memory lets an agent remember selected details.
Choose what it can do
Tools let an agent do more than reply in chat. Give it only the actions its work needs. For each action, choose what should happen:
- Off — the agent cannot use this action.
- On — the agent can use it without asking first.
- Ask — the agent pauses for your approval before using it.
Check these settings before relying on an agent. An approval request lets you review an action; it does not guarantee that the action is safe.
Connect a service and allow access
First add a service in Connectors. Then choose which tools each agent can use. Adding a service does not automatically give every agent access to it.
Enter sign-in details in the service’s credential settings, not in an agent’s instructions or command arguments. Kautuka includes Gmail and Microsoft 365 connections; sending mail asks for approval by default, but each agent can be configured differently.
Add optional skills
Skills are optional sets of instructions and supporting files for particular kinds of work. Add one when an agent needs extra guidance; agents can work without skills.
- Off — the agent cannot use the skill.
- On — the agent may use it when relevant.
- Ask — the agent asks for approval before using it.
Let agents hand off work
One agent can ask another agent to take on a specific piece of work. Choose which agents it may call and whether those handoffs need approval. This is optional; most agents do not need to hand work off.
Advanced setup details
Each agent has a name, selected model, instructions, and optional tone/persona settings. The sandbox setting controls access to workspace-backed tools. Session retention, summary model, and memory extraction are additional options; see Memory for remembered facts.
Connector tools can come from online addresses, local commands, declared container images, or imported packages such as .mcpb. A connector must be added and then allowed for each agent that needs it. Keep credentials in the connector’s credential settings, not in command arguments or URLs.
Skills can include scripts and other files. Review their contents and requested access before importing them. A skill’s name is guidance; it is not itself an action the agent can run. Scripts require the appropriate workspace setting.
An agent can be offered to another agent for a limited handoff. An agent that is offered this way cannot call another agent in turn. Approval can be required for selected handoffs.
Agents: list GET /api/settings/agents (includes revision, the current definition snapshot number); save or delete PUT /api/settings/agents/{agentId} and DELETE /api/settings/agents/{agentId}; effective tool policy GET /api/settings/agents/{agentId}/tool-policy; configuration history GET /api/settings/agents/{agentId}/revisions and diff GET /api/settings/agents/{agentId}/revisions/{revision}/diff.
Persona definitions and profiles: /api/settings/persona/definitions, /api/settings/persona/profiles. Runtime and session transport uses /api/narad/v1.
Connectors: /api/connectors, /api/connectors/{connectorId}; test POST /api/connectors/test; discovery PUT /api/connectors/{connectorId}/discovery; MCPB import POST /api/connectors/import/mcpb; credentials /api/credentials/connector/{connectorId}.
Skills: list and detail GET /api/skills, GET /api/skills/{skillId}; validate and import POST /api/skills/validate, POST /api/skills/import; update or delete POST /api/skills/{skillId}, DELETE /api/skills/{skillId}. The shipped kautuka-docs package is a system-owned help skill: it is installed on startup, enabled on first install, keeps an administrator’s enabled or disabled choice on refresh, and cannot be deleted.
Verify an agent with a new session. For agent-as-tool, invoke it from the permitted caller and confirm one outer tool call contains the child activity and any required approval.