Skip to main content

Coworker Agents overview

Run autonomous agents that work alongside your team — answering Slack threads, handling scheduled chores, and opening pull requests — while MintMCP manages their credentials, tool access, and audit trail.

Coworker Agents is in beta and available on Enterprise and Teams plans. Contact us to enable it for your organization.

How it works​

A coworker agent is a directory in a GitHub repository you connect to MintMCP. New agents are platform-managed: MintMCP holds their configuration and gives each its own identity and connector bundle, while the agent's instructions and memory stay in the repository as files you can read, review, and edit like any other code.

FilePurpose
AGENTS.md (or CLAUDE.md)Instructions: the agent's role, goals, and rules
progress.mdPersistent memory the agent updates across runs
activity-log.csvAppend-only audit trail the agent maintains itself
inbound/Drop folder where people (or other agents) leave tasks

Each run starts a fresh session on MintMCP's hosted runner: the agent reads progress.md and inbound/, does its work, updates its memory and activity log, and commits the results, directly for changes inside its own directory, or as a pull request for anything else. Because memory lives in the repository, the agent picks up where it left off on the next run.

Runs execute in an isolated sandbox with restricted network egress, and compute disappears when the run ends. See Coworker Agents security.

What lives where​

Older agents are GitHub-managed: their configuration lives in an agent.yml file in the repository. Both models run the same way, so the difference is only where configuration and identity live.

GitHub-managed (legacy)Platform-managed (V2)
Configuration (model, tools, triggers, secrets list)<agent>/agent.yml in the repositoryMintMCP; edit on the agent's Settings and Connectors tabs
Identity and connectorsA vMCP you connect by handThe agent's own identity and connector bundle, created with the agent and managed on the Connectors tab
Instructions and memory (AGENTS.md/CLAUDE.md, progress.md, activity-log.csv, inbound/)RepositoryRepository
.github/workflows/<slug>.ymlGenerated from agent.ymlA trigger bridge for scheduled runs, written by MintMCP
Agent card badgenonePlatform V2

Existing GitHub-managed agents keep working, and you can move one to platform-managed with a one-click upgrade. See Upgrade a GitHub-managed agent to the platform.

Triggers​

An agent can have any combination of three triggers:

TriggerHow it fires
Slack mention@-mention the agent's Slack app; it reads the thread and replies in it
ScheduleCron expressions (UTC) for recurring work
ManualThe Run button in MintMCP, with a prompt and model choice

What agents can do​

  • Converse in Slack — each agent gets its own Slack identity, acknowledges mentions immediately, and posts progress in the thread. See Connect a Coworker Agent to Slack.
  • Call your tools through MintMCP — connect a vMCP to give the agent scoped, audited access to your MCP servers. Tool access is a real allowlist: a tool not in the agent's allowed_tools is not callable, even if its server is configured.
  • Ship changes as pull requests — agents work on branches and open PRs for review, and leaving PR feedback becomes input for the agent's next run.
  • Delegate to sub-agents and reuse skills — agents can define sub-agents for focused work and share skills across your organization.

Governance​

The governance model is the same one the rest of MintMCP uses, so agents stay visible and controllable:

  • IT & Security teams get an audit trail on every gateway tool call, session visibility through Agent Monitor, and rules that can flag or block risky actions.
  • Admins control which repositories agents live in, which tools each agent can call, and how its secrets are stored and brokered.
  • Anyone with repository access can read an agent's instructions, memory, and full run history — an agent is reviewable code, not a black box.

Get started​