What your agents run on, and what they work on
Two questions. What an agent works with is the engine — the tool that drives the language model; Claude today, ChatGPT alongside. What it works on is the target system: not a hard-wired connector but a plugin that brings its actions, its events and its own instructions with it. Both are enabled in the interface, given credentials and assigned to an agent.
What they run on
The engine is the tool that drives the language model. What you deposit is how it is paid for: a subscription seat or an API key. Several of them under one name make up a workplace's capacity. covey spreads the work across them, keeps each agent on the same seat where it can, and moves to another as soon as one is used up.
Claude Code (Anthropic)
The engine covey runs on today: Claude Code, without an interface, inside the agent's workplace. It can resume a session — which is what allows an agent to wait for a customer's reply instead of starting over — and it reports its costs and its subscription usage itself rather than leaving them to be estimated. Subscription seat or API key, either works.
Codex (OpenAI)
Set up as a second engine, with both forms of access: the API key as an environment variable, the ChatGPT login as a file that exists only for the duration of the run. We have not yet verified operation against the program itself — and while that is the case, this says "in preparation" rather than "supported".
educa AI
The third engine, and the first that sits in front of a gateway rather than a single provider: educa AI Core serves Anthropic's interface as well as OpenAI's. So covey uses the same Claude Code tool there as elsewhere, just against the educa endpoint. Verified against the hosted instance: runs work, tools are executed, a session can be resumed. One token, two contract forms (by usage or as a quota). We deliberately do not adopt the monetary figure the tool reports — it prices somebody else's contract. The token counts stay, because those are measured.
Further engines
An engine is a plugin that registers itself: one file stating which credentials it needs and in what form, whether it can resume a session, and where it looks for its instructions. The platform checks what it states when the engine is assigned — so the next engine needs no special handling.
Where the work comes from
Zammad
Review tickets, answer them, set the status, escalate. As soon as a customer replies, Zammad notifies covey and the agent is woken — so it does not have to keep checking.
Salesforce
Service Cloud cases as the work to be done: read a case with its whole conversation, find the open ones, look up how the same question was answered before, and reply — as an internal note, as a comment visible in the customer portal, or as a real email. Attachments both ways, status and escalation included. covey checks at intervals whether anything is waiting; Salesforce can also notify it directly.
Zendesk
Support tickets as the working set: read a ticket with its whole thread — rebuilt from the audit trail, so no earlier answer is missed — look at what the customer attached, check how the same question was answered before, and reply: as an internal note or as an answer the customer sees. Set the status, escalate, fold duplicates together. covey checks at intervals whether anything is waiting; if you prefer, Zendesk announces it itself.
GitHub
Issues and pull requests as the work to be done: check out the source, make the fix on a branch of its own, open a pull request with a QA agent as reviewer — including the round that follows on comments and failed checks. GitHub reports new events itself; covey also checks at intervals.
GitLab
Issues as the work to be done, check out the source, make the fix on a branch of its own, open a merge request to the manager — and then work through the round that follows on comments and a failed pipeline.
Jira
The board a company actually plans on — the cloud version as well as the one in your own data centre. Find work with a search query, read a ticket with its history and its screenshots, take it on, move it through its workflow and keep it current with labels, estimates and subtasks. The code stays in GitLab or GitHub; the ticket number connects the two — which is why the agent puts it at the front of every commit message.
Email (IMAP/SMTP)
A mailbox of the agent's own: review the inbox, reply, file things away. For everything that arrives without a portal and without a programming interface.
Microsoft Teams
A chat channel through the Azure Bot Service: receive and send messages. Every incoming call is cryptographically checked for authenticity.
Google Search Console
What a search engine did with a page, as opposed to what the page says about itself: which addresses are indexed, which canonical Google chose instead of the declared one, what somebody searched for before they arrived. Read-only apart from submitting a sitemap, and the OAuth scope is chosen per action: an agent with read access holds a token that cannot write.
Files & documents
Confluence
The documentation that ticket and code hang on — the cloud version as well as the one in your own data centre. Find a page by keyword or search query, read it, append a section, comment, add labels, attach files. No wake-up comes from here: the agent comes to this system while working on something else, and writes when that work is done.
Nextcloud
A file store through a share link or an account: list, read, write, create folders. Access runs over WebDAV — for an agent, the link is enough.
SharePoint / Teams files
The same file operations in the Microsoft world: a document library through a registered application in Entra ID, with exactly the permissions it needs.
Web & sandbox
Browser (headless Chrome)
The fallback for web applications with no plugin of their own: open pages, read text, click, type, save screenshots. Which pages are reachable at all is decided by the allowlist for network access.
Dev sandbox
The agent's own computer: run commands, start development servers and databases, test, and clear them away again.
Vulnerability databases
Known security holes in the libraries in use: in goes the file that pins the versions, out come findings with an identifier, a severity and the version that fixes the problem — matching the version branch in use. For npm, Composer and Dart/Flutter.
Kubernetes
Look into a cluster without changing it: pod states and restarts, the log of a crashed container, events, workloads, ingresses, permissions and network rules. Credentials inside the cluster stay unreadable, and the desired state still comes from the infrastructure repository.
Missing one? Connect it yourself instead of waiting.
Two routes that do not wait for a new release — both in the interface, with nothing to redeploy.
REST system via manifest
A JSON file describes the authentication, the actions and the fields of incoming events. Upload, enable, assign — without a line of program code.
MCP servers
Any server that speaks the Model Context Protocol can be registered as a target system. covey discovers by itself which tools it offers; you decide per agent which of them it may use.
The agent never sees the credentials
No lasting password and no lasting key sits in the agent's workplace. Every access runs through covey's control plane: it checks whether the access is permitted, inserts the credentials only at that point, and writes the operation to the log. What an agent may do is stated in the platform's configuration, not in its prompt.
And the rest of the platform?
Target systems are one half. The other is everything around them that lets you trust a workforce of agents.