> ## Documentation Index > Fetch the complete documentation index at: https://docs.komodor.com/llms.txt > Use this file to discover all available pages before exploring further. # Connections > Everything your agents connect through — what they may reach, which models they run on, where results go. Connections is where the Komodor Agentic Operation Platform (KAOP) meets everything outside itself. There are exactly two ways to connect an agent to something external: the built-in integration catalog, or the [MCP Gateway](https://docs.komodor.com/security-and-governance/architecture-considerations/mcp-gateway.md) for tools of your own. Everything else gathered here supports one of those two — the models agents run on, the credentials they resolve, and the routes work arrives and results leave by. ## Four groups, four questions | Group | Holds | Answers | | - | - | - | | **Agent tools** | Integrations, Integration groups, [MCP Gateway](https://docs.komodor.com/security-and-governance/architecture-considerations/mcp-gateway.md) | What may an agent reach and read? | | **Models** | Model providers | Which models may the fleet call, and what do they cost? | | **Notifications** | [Slack channels](https://docs.komodor.com/manage-your-agents/run/channels.md), inbound endpoints, [outbound webhooks](https://docs.komodor.com/manage-your-agents/run/outbound-webhooks.md) | Which routes carry work in and results out? | | **Supporting infrastructure** | Credentials, Outposts | What carries the secrets, and how does KAOP reach a network it is not inside? | An **inbound endpoint** authenticates a named sender and routes what it posts to an agent or a workflow; creating one walks through the sender, its authentication, a test delivery you can inspect before committing to it, and finally the target. See [Run — how it works](https://docs.komodor.com/manage-your-agents/run/how-it-works.md) for what starts a run, and [Triggers](https://docs.komodor.com/manage-your-agents/build/triggers.md) for why an endpoint is not a trigger. An integration row names its credential, which agents use it, and who added it. **Used by** is the field to read before changing anything — a connection used by every agent is a different object from one bound to a single investigator. Each connection carries two independent states: whether someone finished connecting it, and whether its credentials last worked. An **Active** connection whose last check **Failed** is configured and broken at the same time. The provider catalog, what each provider asks for, and how to test and reconnect are in [Integrations list](https://docs.komodor.com/manage-your-agents/build/built-in-integrations.md#test-and-reconnect). ## How a model entry resolves A model entry is a **name you give a job** rather than the vendor's model string: an entry named `payments-rca` resolves to a dated vendor model behind it, so the model doing that job can be changed without touching the agents that ask for it. A **Komodor gateway budget** caps every Komodor-managed model for the account. Which models exist, who manages each one — Komodor, a provider connection of yours, or an LLM gateway you run yourself — and what each has spent are covered in [Providers](https://docs.komodor.com/security-and-governance/architecture-considerations/providers.md). ## What a credential shows The list shows how many keys a credential holds and which ones, alongside its access, environment and provider. That tells two credentials for the same provider apart without opening either, and makes an incomplete credential visible before an agent fails on it. How a stored secret reaches a run is covered in [Credentials & secrets](https://docs.komodor.com/security-and-governance/identity-and-access/credentials-secrets.md). ## Outposts An **Outpost** is a relay installed inside a private network so agents can reach tool servers with no inbound path to KAOP: the Outpost is inside the network and dials out, so nothing is exposed. See [Outposts](https://docs.komodor.com/security-and-governance/architecture-considerations/outposts.md). ## Integration groups An integration group bundles tool servers behind a single per-group MCP Gateway endpoint, so an agent is attached to a named set rather than to a dozen connections individually. A group may hold servers from the integration catalog and from the MCP Gateway together, so it spans both connection paths. Groups also **narrow**: allow and deny rules mean the same underlying connection can hand one agent a read-only slice and another the full surface, without duplicating the credential. See [Integration groups](https://docs.komodor.com/manage-your-agents/build/integration-groups.md). When tool definitions change on a server, **Reload gateway** re-reads them so agents see the current surface rather than the one discovered when the connection was made. ## Next steps > [card] [Integrations list](https://docs.komodor.com/manage-your-agents/build/built-in-integrations.md) > > The provider catalog, and what each one asks for. > [card] [Triggers](https://docs.komodor.com/manage-your-agents/build/triggers.md) > > Inbound endpoints, and why they are not triggers. ## Related topics - [Outposts](https://docs.komodor.com/security-and-governance/architecture-considerations/outposts.md) - [MCP server](https://docs.komodor.com/developer-tools/mcp-server.md) - [Network & egress control](https://docs.komodor.com/security-and-governance/architecture-considerations/network-egress-control.md) - [Integrations list](https://docs.komodor.com/manage-your-agents/build/built-in-integrations.md) - [APM](https://docs.komodor.com/manage-your-agents/build/catalog/apm.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.