Skip to main content

Managing agents

Agents are the working units of EnClaw — each one is a named, governed AI worker with its own identity, model configuration, skills and channel presence. This page covers the full lifecycle an org admin manages at /agents, from creating the first agent to scheduling, heartbeat tuning and per-agent skill control.

EnClaw distinguishes two kinds of agents:

  • Org agents — shared, admin-managed, visible to the teams they're assigned to. Managed at /agents.
  • Personal agents — owned by a single user, isolated to that user. Users manage their own at /my-agents. Personal agents never answer anyone except their owner (see routing rules below).

Agent lifecycle​

Create, edit and archive agents from /agents. Every agent moves through three statuses:

StatusMeaning
ActiveAvailable for chat, routing, schedules and heartbeat.
InactiveKept with all configuration intact, but won't take new work. Use this to pause an agent without losing anything.
ArchivedRetired. Hidden from everyday lists; transcripts and audit history are retained.

Prefer inactive over deleting when you're unsure — reactivating is a single toggle, and session history stays attached.

Each org agent is assigned to a team, which scopes who can see and use it. Personal agents instead carry an owner — the user they belong to.

Agent identity — the Markdown prompt​

An agent's identity is a Markdown document that defines who the agent is. It becomes the core of the agent's system prompt, so it's the single highest-leverage thing you'll write. A good identity contains:

  • Role and mission — one or two sentences on what the agent is for ("You are the delivery PM assistant for the Professional Services team...").
  • Scope and boundaries — what it should and shouldn't attempt, and when to hand off to a human or another agent.
  • Tone and audience — who it talks to and how (formal client-facing vs internal shorthand).
  • Working knowledge — team conventions, naming standards, key systems, definitions the agent should treat as ground truth.
  • Tool guidance — which tools to reach for first, and any "always confirm before sending" style rules.

Keep it concrete and specific. Vague identities ("be helpful and professional") produce generic agents; specific ones ("weekly status reports follow the RAG format; always cite the ticket key") produce agents your team trusts.

The Orchestrator​

Every workspace has one system agent created automatically: the Orchestrator. It's the front door for queries that aren't addressed to a specific agent — it reads the request, looks at the catalogue of available agents (including the requester's own personal agents), and routes the query to the best specialist.

The Orchestrator also applies sticky routing: it remembers which agent last handled a conversation for a given user and channel, so follow-up messages stay with the same specialist instead of being re-routed mid-task.

You don't need to configure the Orchestrator for basic use, but you can tune its identity and model like any other agent. Don't archive it — unrouted queries need somewhere to land.

Channel bindings and routing rules​

Agents can be bound to specific messaging channels (a Slack channel, a Teams channel, a Telegram group) from the agent's settings. Bindings change routing behaviour, and the rules are strict by design:

  1. Binding is exclusive. An agent bound to a channel answers only in that channel. It won't pick up direct messages or other channels' traffic.
  2. Unbound queries fall to the Orchestrator. A message in a channel with no bound agent goes to the Orchestrator, which routes it to an eligible specialist.
  3. Personal agents only ever answer their owner. A personal agent is never eligible to respond to anyone other than the user who owns it, on any channel or fallback path.

These rules exist so that an agent set up for one team's channel can't leak into another team's conversations, and so one user's personal assistant never answers a colleague's message. If an agent seems to have "gone quiet" in DMs, check whether it has been bound to a channel — that's usually the cause.

Agent templates​

Templates give you a pre-built identity, skill set and configuration you can provision in one click. EnClaw ships 12 built-in templates:

TemplateCategory
Project ManagerProject management
RFP AgentProject management
Content AuthorCommunication
Social Media AgentCommunication
CRM AssistantAnalytics
Health MonitorAnalytics
Business AnalystAnalytics
Coding AgentDevelopment
PR Review AgentDevelopment
Testing AgentDevelopment
UI/UX DesignerDevelopment
Customer SupportSupport

You can also save any existing agent as a template — useful once you've tuned an agent's identity and skills and want other teams to start from the same baseline rather than a blank page.

Model configuration​

Each agent chooses its own model at agent → Edit → Model:

  • Primary provider + model — what the agent normally runs on.
  • Fallback provider + model — automatically used if the primary provider fails or is unavailable. Pairing a primary with a fallback from a different provider gives you resilience against a single vendor outage.
  • Token budget — a per-session cap on token consumption. When an agent approaches its budget it wraps up with a summary rather than running open-ended. Tune this down for chatty low-stakes agents, up for long research tasks.

Providers themselves are configured once at the workspace level — see LLM providers. Agents can only pick from providers your workspace has active.

Agent–user assignment​

Beyond team scoping, you can control which users may use a given agent:

  • Team assignment — the default scoping unit; users in the team see the team's agents.
  • Per-user assignment — grant or restrict access to a specific agent for specific users, independent of team membership.

Combine this with permission rules when you need finer control over what an agent may do, not just who may use it.

Scheduling​

Agents can run on a schedule without anyone typing a prompt — daily stand-up summaries, weekly report drafts, hourly queue checks. Configure schedules on the agent's Scheduler tab:

  • Cron-based recurrence — hourly, daily, weekly, monthly, or a custom cron expression, with a visual builder that previews upcoming runs.
  • One-time schedules — run once at a specific date and time.
  • Timezone per schedule — each schedule carries its own timezone, so "9am Monday" means 9am in the team's timezone regardless of where the platform is hosted.
  • Target agent — a schedule can run on a different agent than the person who created it, so an admin can set up recurring work on behalf of a team agent.
  • Smart catch-up — if the platform was down or the agent was paused when a run was due, a schedule missed by more than a couple of hours triggers a single catch-up execution rather than replaying every missed run.
  • Concurrency guard — EnClaw limits how many scheduled executions run at once, per agent and globally, so a burst of overlapping schedules can't starve interactive users.

Heartbeat and Do Not Disturb​

The heartbeat is an agent's proactive pulse: on a configurable interval, the agent reviews its open threads and follow-ups and decides whether it has something genuinely worth telling someone — a follow-up suggestion, a detected pattern, a task that's gone stale. Configure it on the agent's Heartbeat tab.

To keep this useful rather than noisy:

  • DND hours — set a start hour, end hour and timezone per agent. Outside those hours the agent stays silent; pending notes are delivered in the last window before quiet hours begin rather than dropped.
  • Delivery throttling — proactive messages are rate-limited platform-side, so even an over-eager agent can't flood a channel.
  • Note lifecycle — undelivered notes eventually expire, so a week-old "reminder" never surfaces as if it were fresh.

Heartbeat is per-agent: it's reasonable to enable it on one or two high-value agents (a PM assistant, a monitoring agent) and leave it off elsewhere.

Per-agent skill control​

Every agent has a Skills tab listing the skills and tools available to it, each with an enable/disable toggle. This is how you shape an agent's capability surface — a content agent probably doesn't need code execution; a coding agent probably doesn't need CRM write access.

Two levels interact here:

  • Agent-level toggles — what this particular agent may use.
  • Org-level disable — a skill disabled at the organisation level is off for every agent, regardless of the agent-level toggle. Org-level disable always wins.

So an agent's effective toolset is: enabled on the agent and not disabled at the org level and permitted by permission rules. For custom and marketplace skills and how they enter the catalogue in the first place, see Custom skills.

Next​