Register an agent

Give a company agent its own identity and key, choose its jobs, and hand its builder the setup.

Each company agent (a deployed agent, a workflow, an automation, an app) is its own identity in Felspar: its own key, the jobs it may run, and an accountable person. It can run decisions. It can never propose, approve, release or read review material.

Register

You must be the workspace owner or an approver.

1. Open Workspace on app.felspar.ai and find Company agents.
2. Name the agent after the deployed system, such as “Support Triage Bot” or “Contract Intake”. Use one agent per system, so you can revoke it on its own.
3. For each job it may run, choose:
   • Latest (follows each approved release): the default. The agent gets each new release automatically.
   • Pinned: the agent stays on one release you choose until you change it.
   • Not allowed: the agent can’t run the job.
4. Click Register agent.
5. Copy the key now. It is shown once. Store it in your secret manager or deployment environment. Never paste it into chat, a prompt or Git.

You become the agent’s accountable person.

Choose Latest or pinned

Default to Latest. Pin only for a contractual promise tied to one version, a regulated decision that needs a validated version, or trying a new release on one agent first. Pinned agents don’t get fixes; move them deliberately. See Latest and pinned.

Hand over the setup

Give the builder three things: the address, the key (through your secret manager), and the setup for their surface.

The agent sees four MCP tools: list_jobs (the jobs this key may run, with each one’s purpose), get_job_requirements, get_job_decision and check_output (for text it writes after a decision). One agent can run every job it’s registered for and pick between them with list_jobs. The code that acts on a decision verifies the receipt over REST with the same key.

Install the Felspar method as the agent’s skill: npx @felspar/sdk skill writes it to agent/skills/felspar/SKILL.md (pass another directory, such as .claude, and --force to replace an existing copy). Then tell the builder:

• send the source’s exact words for each question, never a label;
• send the case’s ID exactly as the brief’s subject.send says, and related records’ IDs under related;
• act only on Felspar’s outcome; treat “not decided” as unresolved;
• when a result carries escalation, hand the case off by its id: Felspar names the hand-off and your code decides what it does;
• verify the receipt before a consequential action.

Check it works

Have the builder run one decision. The workspace page lists each agent with its jobs (Latest, with the release it’s on now, or Pinned), and when it was last used.

Change jobs

On the workspace page, change the agent’s jobs or pins and click Save jobs. The change applies on the agent’s next call.

Revoke

Click Revoke this agent and confirm. The agent’s very next call is refused, over MCP and REST alike, and its key is deleted. A revoked agent is never reactivated; register a new one if you need it again. Revoke a key that may have leaked rather than waiting.

What an agent can and can’t do

A 403 for a job usually means the agent isn’t registered for that job. Add the job on the workspace page.

Related

• MCP tools
• REST API
• The pre-action gate