Kata CI GuideApps and tools
Give agents the ability to act, explicitly and under policy.
Tools turn an agent from an advisor into an operator: searching systems, posting messages, reading drives, calling internal APIs. Access is always explicit. An agent gets the capabilities its purpose requires, nothing more.
Connected apps
Your deployment ships an app catalog spanning communication, files, CRM, development, and analytics tools: Slack, Google Drive and Sheets, Salesforce, HubSpot, Notion, GitHub, Jira, BigQuery, Postgres, and dozens more, organized by category under Console → Resources → Apps.
The flow:
Install the app into the workspace.
Connect an account. Two modes, and the difference matters:
- A workspace account acts for an official process. Messages sent through it carry the shared identity.
- Personal connections have each user connect their own account, so the agent acts as that person, with that person's access.
Bind capabilities to the agent. Pick which of the app's capabilities this agent gets. A reporting agent might get read-only file access and nothing else.
Action policy
Every binding carries an action policy. Read-only blocks anything that changes external state. Full allows the app's actions to run. Start read-only, upgrade deliberately, and pair Full access with approvals where the action is consequential.
Packs
A pack bundles related skills and tools that travel together, installed as one unit from Console → Resources → Packs. Ava's Data Analytics pack, for example, brings the full analytical skill set in one install. Reach for a pack before assembling the same capabilities by hand.
Custom tools with MCP
Anything that speaks MCP can become agent tooling: internal APIs, databases, line-of-business systems. The app catalog's MCP Server entry takes a URL plus headers and connects any server that speaks the protocol. Verify the connection to see its tools, then bind it to agents like any other resource.
This is the standard route for customer-specific integrations. Your internal engineers or Kata CI FDEs wrap the system in a small MCP server, and every agent in the workspace can be granted it.
Secrets
Credentials for apps and MCP servers are stored as workspace secrets, write-only after creation. Rotate them from the Console without touching agent configuration.
Grant by purpose, not by availability. The question is never "what could this agent use" but "what does this work require". Anything beyond that is risk with no return.