Pre-built connectors let an AI agent receive events from and send results to the systems around it, such as webhooks, message queues, databases, email, and MCP clients, without you writing and maintaining the integration code. They turn event plumbing into a platform feature instead of custom glue, which is usually the slowest part of getting an agent into production.
The plumbing problem
Most guides stop at the model call. Production starts after it. Your agent has to be triggered by a real event and has to put its output somewhere a person or system will see. That means a webhook handler with signature validation, a queue consumer with retries and a dead-letter queue, backpressure when traffic spikes, and credentials stored safely. None of it is an AI problem, and all of it is code you then own forever.
Webhooks, Kafka, queues, databases, email, and more, wired up as configuration so you ship the agent instead of the plumbing.
Try Connic freeWhat a connector handles for you
A pre-built connector is the integration layer between your agent and an external system, run by the platform. Instead of writing and maintaining that code, you point the agent at the connector and it handles the parts that are the same for everyone:
- Receiving and parsing the inbound event (HTTP, queue message, database notification, email).
- Authentication and signature validation, so you trust the source.
- Retries, backpressure, and dead-letter handling when something fails.
- Sending results back out to the system that should act on them.
The connectors Connic ships
Connic provides first-party connectors for the systems agents most often plug into, so the plumbing is configuration rather than code:
| Connector | Typical use |
|---|---|
| Webhooks (HTTP) | Run an agent on any inbound HTTP request. |
| Cron | Run an agent on a schedule: digests, checks, audits. |
| Apache Kafka | Consume topics to trigger agents, produce results back. |
| AWS SQS | Drain queues with retries and dead-letter handling. |
| AWS S3 | Run an agent when a file lands in a bucket. |
| PostgreSQL | Trigger on new rows via LISTEN/NOTIFY, no polling. |
| Email (SMTP/IMAP) | Read an inbox to trigger, reply by drafting a message. |
| Stripe | Run an agent on Stripe events; signing is handled. |
| Telegram | Build chat-driven agents on Telegram. |
| WebSocket | Stream tokens to the browser over a live socket. |
| MCP | Expose agents as callable MCP tools for MCP clients. |
See the full list on the connectors page.
Inbound, outbound, and sync
Connectors work in three directions. Inbound connectors trigger an agent from an external event. Outbound connectors send an agent's results to an external system. Sync connectors do both in one request and return a response, which is what you want for a chat UI or an API call. Many connectors support more than one mode, so the same Kafka or email integration can both start a run and deliver its output.
Where MCP fits
MCP (the Model Context Protocol) is one connector in the set, not the headline. The MCP connector publishes your agents as callable tools, so an MCP client such as Cursor or Claude Desktop, or another agent, can invoke them over a standard protocol. It is useful when you want your agent reachable as a tool, and it sits alongside the event connectors above rather than replacing them.
When you still write custom integration code
Pre-built connectors cover the common systems. For an internal or niche system with no connector, you write a custom tool, which is a normal function the agent can call. If that system lives inside a private network and is not reachable from the public internet, route the connection through a private network bridge rather than exposing it. The goal is the same: keep the integration work to what is actually specific to you.