How an agent gets access to a target system

An AI agent that can only talk is no use to anybody. It becomes useful once it works in the systems where the work actually is: the ticket system, the source control, the mailbox. We call those systems target systems, and how an agent gets access to them is one of the questions we have thought through most carefully.

This post describes the path from connecting a system to the first call.

A target system is a plugin

We could have built a fixed connector into the program for every system. Every new connection would then have been a new version of Covey, and anyone needing something else would have had to wait for us.

Instead, every target system is a plugin, and every plugin brings three things with it:

Actions. The list of what an agent can do here: answer a ticket, set a status, create a branch. Every action has named parameters, and the platform checks them before anything happens.

The handling of incoming events. When the target system reports something on its own — a customer has replied, a pipeline has gone red — the plugin decides whether that becomes a wake-up for an agent.

A description for the model. Every plugin explains in its own words what its actions are for. That text goes into the agent's prompt. So a plugin brings not only the mechanics but the instructions too.

Four routes to a new connection

A plugin can reach an installation in four ways, and all four are equal.

Some plugins are built in, because they need something that cannot be expressed any other way. Others live in a catalogue behind a web address and are installed at runtime. A catalogue entry points to a file together with its checksum, so what gets loaded is always exactly the version that was reviewed.

Anyone wanting to connect a system with an ordinary programming interface writes a manifest: a JSON file describing authentication, actions and event fields. Upload, enable, assign — without a single line of program code.

And finally, any MCP server can be registered. Model Context Protocol is a widely used standard for tools made available to language models. Covey discovers by itself which tools such a server offers, and you decide per agent which of them it may use.

One thing mattered to us here: our own plugins have no better standing than anyone else's. Three connectors that used to be built in have since moved into the catalogue — precisely for that reason. An extensibility you step around yourself is not one.

The agent never sees the credentials

Now the part that matters most to us.

The obvious approach would be to place an API key in the agent's working environment. But then the key would sit permanently in a place a language model reads and writes. It would end up in log files, it could be copied into a file, and it would be contained in every backup of that environment.

So with us, credentials stay in the control plane — the central part of the platform that also does the planning. They are stored there encrypted and they do not leave it.

When an agent wants to perform an action, the call goes through the control plane. It checks whether this agent may perform this action on this system, inserts the credentials only at that point, and writes the operation to the log. The agent gets the result. It does not get the key.

This has a pleasant side effect: because every access passes through that one place anyway, the record is complete without having to be built separately. What an agent did in a target system is documented afterwards without gaps.

And it draws the boundary in the right place. What an agent may do is not stated in its prompt but in the platform's configuration. A prompt is text the model interprets. A rule in the control plane is a rule.

How setting it up works

Connecting a target system used to be a switch and a longer passage of explanation — five steps across three pages, some of them in a different system. Today a wizard walks through the order:

1. Enable the target system.
2. Deposit the credentials.
3. Assign the agent that will work with it.
4. Copy the address for incoming events — already containing the right identifier.
5. Test the connection.

Which steps appear at all is decided by the plugin. A system with no incoming events does not show step four. And each step asks the server for its state instead of remembering what you clicked earlier — leave the wizard halfway through and you will find it next time where things actually stand.

What the agent notices

From the agent's point of view, none of this is visible. It sees a list of actions it can perform, with the description the plugin brought along. It calls one of them with parameters and gets a result.

That a permission check sits in between, that a log entry is created, and that credentials it never sees are inserted, is none of its business. Which is exactly right: the boundaries are drawn by the platform, not by the model's self-restraint.