Core concepts

A handful of ideas explain every design decision in these docs. Read this once and the rest falls into place.

Orchestration is an agent, not an endpoint

The valuable thing Prscnt does is compose — an LLM reads a situation, decides which tools to call across Prscnt and your own systems, and sequences them with judgment. That is an agent loop. It cannot be reduced to a REST call, because a REST call can't decide which calls to make.

The practical consequence: if you wire your tool to flat data endpoints, you lose orchestration and end up reimplementing the logic yourself. So the integration pattern is always UI → agent runner → write back, where the runner is an LLM that has the Prscnt MCP (and your connectors) attached. You don't rebuild the brain; you point an agent at it.

Workspaces

Everything you do happens inside a workspace — your agency's isolated tenant. Your roster, deals, voice profile, and contract playbook live there.

The workspace is resolved from your credential, server-side. You never send a workspace id; if you try to pass one that isn't yours, the call is rejected. This is the core multi-tenant guard. (If a tool lists workspace_id as a parameter, leave it blank — the server fills it in.)

Read vs. mutating tools

Every tool is one of two kinds:

• Read / intelligence — looks something up and returns it. No state changes. Safe to call freely, including from an automated agent. (rate_benchmark, brand_reliability, roster_match_brand, voice_draft, ar_status, …)
• Mutating — changes pipeline state. (deals_update_stage, deals_bulk_create, the invoice_* writers, roster_* writers, …)

A headless agent should treat mutating tools with care — gate them behind a human approval step. See Security & guardrails.

Human approval on outbound

Prscnt drafts but never sends. Outreach, contracts, and invoices are produced for a human to approve and ship through your own connector. The orchestration runner enforces this by default: it blocks outbound/destructive tool calls and returns them as proposed actions unless you explicitly opt out. This is deliberate — a brand inbox is not a place for an unsupervised agent.

Composition, not migration

Prscnt does not ask you to move your data. It composes the tools you already run. The only Prscnt-side state about your external systems is a thin pointer (a Prscnt deal ↔ a record id + URL in your CRM). Your data stays where it is. See Compose your stack.

Metering is shared

Access is metered against your workspace's plan — the same whether a human is chatting in Claude or your runner is firing calls headless. There's a per-tier rate limit, a monthly allowance on metered tools, and seat caps. Budget your agent's call volume accordingly. See Limits & billing.

Glossary

• MCP — Model Context Protocol, the JSON-RPC interface an LLM uses to call tools. Prscnt is an MCP server.
• Connector — an MCP server for one of your tools (Gmail, QuickBooks, your CRM). You connect these; Prscnt composes them.
• Runner — a small process that hosts an LLM agent with the Prscnt MCP attached, so a non-LLM UI can trigger orchestration over HTTP.
• Plugin — the prscnt Claude Code plugin: the MCP plus a full set of skills, subagents, and slash commands. The portable "full brain."
• Pointer — a stored link from a Prscnt deal to a record in your system (stack_link_deal). Not a copy of your data.
• Pipeline — Prscnt's deal funnel: stages from sourced through signed, campaign, invoiced, paid.