The admin agent

Administer ContextWorks by conversation: draft briefs from a document, check health, compare two entities, publish a draft after approving its exact content. It runs as its own Agentforce agent or MCP server, separate from the runtime tools — set it up on Deploy → Agentforce, step 3a or Deploy → MCP, steps 2a–6a. It requires the ContextWorks Admin or ContextWorks Domain Manager permission set, and every call runs as you — domain managers get their domains, not the org.

How it works

Three rules govern what the agent may do:

  • Reads are unrestricted. Health, the change log, the catalog, the configuration graph — aggregates and configuration, never record data.
  • Drafts reach no one. The agent composes briefs, skills, and entity text freely, because a draft serves no agent until it’s activated.
  • Publishing needs your approval on exact content. Activating, binding to a domain, and deactivating each preview first: the response shows exactly what will serve (or how routing changes) plus a digest. The agent shows you the preview, and commits only with your yes and that digest. If the draft changed since the preview, the commit is refused — content you never saw can’t be published on an old approval.

What you can do

You want to…The agent uses
See what agents receive, per domainGet Catalog
Check usage, quality, issues, trends, or writesGet Health
See who changed what, and whyGet Change Log
Audit the configurationGet Full Config
Draft a brief, a skill, or entity textSave Draft
Publish a draftActivate Draft
Change what a domain carriesUpdate Domain Contents
Pull something from service nowDeactivate
Run a packaged procedureGet Skill · the skills

Limitations

The agent cannot delete artifacts, change settings, grant access, or touch the write-access switches — those stay in the Studio and Admin tabs. Entity structure (fields, related lists, levels) is also Studio-only; the agent drafts entity text.

What’s next