Overview
Deploying puts curated context in front of agents. Every surface calls the same invocable actions, so the same entities serve all of them at once.
The Deploy tab opens on the Deployment Overview: what the org can tell you about where ContextWorks already runs, plus the traffic that has actually arrived. The pages after it set up each surface.
The actions
| Action | Purpose |
|---|---|
| Get Catalog | Discovery — what context exists, and per entity the full contract: fields, valid values, filterable and writable fields |
| Find Records | A filtered set with curated columns and totals |
| Get Records | One or more records in depth |
| Update Records | Change declared-writable fields on one or more records, with a user-confirmed diff — optional, and off at the org level until an admin enables write access |
| Create Records | Add records on declared-creatable fields, through the same confirm-then-commit flow. Governed separately from updating: an org can permit one and refuse the other |
| Get Briefs | The frame the data should be read in — methodology, brand voice, glossary, policy |
| Get Skill | One skill’s full procedure and the shape its result must take |
| Get Info | One computed fact about the situation the question is asked in — the fiscal calendar, the org’s currencies, who reports to whom |
Agents should call Get Catalog first. It stops them guessing object and field names. Register Update Records only where writes belong: an agent without the tool cannot write at all. The Agentforce topic and the MCP tool list carry all eight.
Full inputs are in the invocable actions reference.
Choose a surface
| Surface | Use when |
|---|---|
| Agentforce | You’re building in Salesforce’s agent platform |
| MCP | Claude or another MCP client should reach your org |
| Prompt Builder | A prompt template should be grounded in curated context |
| Custom tools | You want purpose-named tools scoped to a domain |
| Apex API | Flow, scheduled jobs, your own code |
Surfaces aren’t exclusive. Adding a second one requires no configuration changes.
Generic actions or scoped tools?
Start with the generic actions. They cover every configured object, and the Deploy pages generate the registrations for you. Add scoped tools when an agent should pick a tool by its purpose, or when a tool should answer over one domain only. Both can coexist: a scoped tool is a thin class over the same API.
The Agentforce extension package
The core package ships the invocable actions; putting them in front of an agent is a per-org step. MCP and custom tools you register by hand, once. For Agentforce, a second package does it for you.
The extension package holds the Agentforce metadata the core package leaves out: the eight runtime agent actions, the admin ones, and two ready-made topics. ContextWorks carries the runtime tools, and its instructions tell an agent to discover first, then find, then get. ContextWorks Administration carries the admin agent’s actions.
On Deploy → Agentforce, click Install in step 2 and the actions exist, named exactly as the generated AgentScript expects.
It ships separately because that metadata requires Einstein generative AI — orgs without Agentforce install the core package clean. Registering by hand still works; the same page lists every class and the name to give it.
WARNING
Name each registered action or tool exactly as the Deploy page shows. Generated AgentScript references actions by name, and a mismatch fails at runtime — not at save.