Persistent agents

A persistent agent is a named assistant you configure for ongoing work. Its identity, instructions and history survive browser sessions. It can receive messages, react to configured events and run on a schedule. Idle agents do not need a continuously running sandbox.

Create your first agent

1. Open Agents in your organization, then choose New Agent in the sidebar.
2. Enter a name and instructions describing its purpose and how it should report back. Composal generates a readable, organization-scoped link such as /vex/agent/garrytan. Names are reserved automatically; collisions receive a short suffix. Existing identifiers keep working.
3. Choose its work repositories and connected app accounts, then save the configuration.
4. Open its conversation and send a message. The dashboard can activate a ready draft when sending its first message. API clients explicitly activate the saved revision before sending work.
5. Follow its task status and reply in the conversation, or check Agent Inbox for outcomes across agents.

Agents are general purpose: your instructions and selected tools define their work. A draft can exist while its private repository is being initialized; wait for setup to finish before activation.

Share with your organization

New agents are shared with their organization by default, including future members. Current organization members can view their history, memory and files, and send messages. The owner and explicitly granted managers control settings, activation and other management actions. Sharing does not grant management rights to organization administrators.

Use Settings → Share with organization to change access. Private agents remain available only to their owner and explicitly granted members. Existing agents become organization-shared when this feature rolls out. Owners and managers can switch them to private afterward. Organization sharing never makes an agent public on the internet.

Messages use the agent's configured tools and selected app accounts under its owner's execution identity. Only the owner can change those account grants. Share agents whose configured capabilities and retained information are appropriate for your organization. Changing an audience can invalidate provider-event consent; the owner must review and authorize the new audience.

Choose what it can use

Each agent has its own private repository for configuration and durable state. Its work repositories are a separate set you select. Adding a work repository gives read and write access; repository permissions and branch protections still apply. Instructions and memory stay with the agent rather than being added to each work repository.

Agents run with Full Access by default. This applies to their authorized tools and resources; it does not give access to another user's private agent or an unselected repository/account.

In Settings, configure instructions, skills, tools, work repositories, app accounts, memory policy, model policy and spending/execution limits. Saving creates a configuration revision. Activate that revision to use it for new work; an already admitted task keeps its pinned configuration and limits.

Use Connections to connect supported Composio apps or add a custom HTTPS MCP server, then select the exact account in the agent's Settings. The catalog includes existing automation integrations and additional popular Composio apps. Custom server credentials are collected during connection setup. An integration's available agent tools and its support for incoming provider events are separate capabilities.

Run without an open chat

Configure Triggers for schedules, incoming webhooks and supported platform/provider events. A trigger delivers an input to the agent; it does not require a user to keep the conversation open. Use the preview and authorization steps shown for each trigger before activating the revision.

For a webhook integration, create an agent webhook endpoint, save its signing secret securely, bind the endpoint to the agent's trigger configuration and activate that revision. Sending an arbitrary unsigned request does not grant execution authority. See the API reference for endpoint management and the generated schemas for signing and payload requirements.

Pause an agent to stop admission of new execution. Archive it when it should no longer run. Stopping a task is a separate action: effects already started can still require reconciliation. These lifecycle actions do not delete its history.

Follow work and replies

Message acceptance is a durable receipt, not a completed answer. A conversation shows the accepted input, its task status and the saved result when available. An agent can also wait for your answer or an approval. A failed, cancelled or blocked task is not a successful reply; inspect its reason.

Limits can stop a task before it finishes. A lost provider acknowledgement can require reconciliation. Keep the original task/input identities when investigating, and avoid submitting the same work as a new message merely because its answer has not arrived.

Choose an integration surface

• HTTP API: create, configure, activate, message and manage agents from your application. Read conversations, task outcomes and versioned state.
• CLI and MCP: manage the same agents using com agent or the local MCP server's com_command tool.
• Coding-agent setup: install skills and tools into an external coding assistant. This is separate from creating a persistent agent.

The HTTP API is the integration contract today. composalai/agent-sdk is planned; no dedicated agent SDK is available yet.

Archived agents keep their history. Owners and managers can still make that history private; this does not reactivate the agent or restore messaging.