Platform Functions
Workspace-registered SQL, AI, Python, and table-valued functions for governed data retrieval and computation.
API Name: Platform functions are managed through the Agent Forge CLI, the platform SDK, and the Developer Console's Warehouse tab (Tools > Warehouse), which provides a read-only directory, inspector, and test runner, in addition to the workspace-scoped functions endpoints. See the Developer Guide for endpoint details.
Platform functions are workspace-registered computation tools. You define a supported SQL, AI, Python, or table-valued function and deploy it to the workspace function registry. Supported agent runtimes can then expose that function as a tool and return its result to the agent.
The key capability is cross-domain querying. Platform functions can read both live entity data (the world model's operational store) and analytical aggregations (historical trends, billing data, population statistics) in a single call when the registered SQL has access to those sources. A function might combine an entity's current projected confidence fields with a separately defined utilization aggregate.
Tool Categories
Each successfully loaded platform function registers as a tool with a name, description, input schema, and result. Two related families can load at session start:
Named platform functions - addressed as
fn_<name>, these are pre-built queries or computations registered for the workspace. Each runs on the platform's compute layer.Workspace data queries - addressed as
wsq_<name>, these are parameterized SQL templates that run directly against a workspace's own custom tables. Parameters are typed with optional defaults, write-time validation rejects multi-statement and session-state SQL, and execution runs under the workspace's tenant-scoped role.
Named Functions
Named functions are pre-built queries or computations registered for the workspace. Each function has a name, description, input schema, and return type. The agent calls them by name with structured parameters.
Function types:
SQL
Parameterized query that returns rows or a single computed value across live and analytical data
Patient summary, caller history, entity confidence assessment, risk score
AI
A query that wraps an AI operation such as classify, summarize, extract, or assess
Intent classification, clinical extraction, transcript cleanup, care plan generation, handoff summaries, urgency assessment
Python
A sandboxed scalar function for custom logic
Address parsing, custom scoring algorithms, phone formatting
Table-valued
A sandboxed function that returns multiple rows
Expanding a record into per-line-item rows, derived tabular results
Deployments can expose common world-data functions, and a workspace can register additional named functions. The session runtime loads functions that are registered for that workspace; do not assume a warehouse function is automatically present as an agent tool.
Common Function Names
Depending on deployment and workspace registration, common examples include:
Entity confidence - Current projected source, event count, confidence value, and last-event time for an entity (SQL)
Caller history - Recent call dates, outcomes, quality scores, and conversation summaries for a phone number (SQL)
Patient summary - Current display name, entity type, event count, source, and last-event time (SQL)
Workspaces can register additional SQL, AI, Python, and table-valued functions. The callable set for a session depends on workspace registration, successful loading, the selected runtime, and any applicable Context Graph bindings.
Workspace Data Queries
Workspace data queries (wsq_<name>) cover the long tail of questions that no pre-built function anticipated, such as "how many appointments did this patient cancel in the last 6 months?" or "which providers at this location accept this insurance?" A team registers these as parameterized SQL templates that run against custom tables provisioned for the workspace. Parameters are typed (string, integer, number, boolean) with optional defaults, and write-time validation rejects multi-statement SQL and session-state commands. Query access remains constrained to the workspace's provisioned tables.
Platform functions are read-only. Recording new observations as world model events is done through the dedicated write tools described in Clinical Tools and the World Model page, not through this surface.
Loading Functions at Session Start
Registered functions and workspace data queries are loaded at session start from the workspace stores. A load failure can leave a function unavailable for that session. In the state-machine runtime, tool_call_specs normally determines state-level visibility. Some hosted native or realtime agent runtimes attach supported shared platform tools across their phase agents instead. Validate the runtime used by the service rather than assuming one universal gating rule.
Using Functions in Context Graphs
For the state-machine runtime, bind a function through tool_call_specs on each Context Graph state that needs it:
Named platform functions use the fn_ prefix, becoming fn_{name} (e.g., fn_caller_history, fn_risk_score). Workspace data queries use the wsq_ prefix, becoming wsq_{name}.
This keeps function access contextual on that runtime - a triage state might expose fn_entity_confidence and fn_caller_history, while a data-capture state exposes relevant workspace data queries. Other supported agent runtimes can use a shared-tool contract; consult their runtime documentation before relying on state-level hiding as an authorization boundary.
Management
Platform functions are managed through workspace-scoped REST endpoints, the platform SDK, and Agent Forge - see the developer guide for endpoint details. Deploying a function name that already exists replaces the definition in place (no versioning or aliases), and functions registered in one workspace are independent of other workspaces.
Agent Forge CLI
Agent Forge provides function management commands:
How Tool Types Relate
The platform has three complementary tool types. Each serves a different purpose:
Definition
Declarative (SQL, AI, Python, table-valued)
Imperative (custom code packages)
LLM-backed micro-agents with prompt-based configuration
Deployment
Register and run - no container or build step
Package with dependencies, deploy to execution environment
Configure prompt, schemas, model, and declared tools
Data access
Read access granted to the registered function runtime
Defined by the packaged Action and its credentials
Through declared integration and static tools
Write capability
None - read-only; writes go through dedicated write tools
Defined by the package and its authorized integrations
Delegated through declared tool calls
Latency
Warehouse or compute startup can add delay
Depends on the deployed Action and execution environment
Bounded by configured timeout and agent-turn limits
Best for
Data retrieval, scoring, classification, summarization
Multi-step workflows, external system integration, document generation
Prompt-driven reasoning and orchestration over declared tools
Use platform functions when the agent needs data or computation. Use Actions on the Classic API when the agent needs a versioned code package. Use Platform Skills when the task requires model-driven reasoning or multi-step orchestration over explicitly declared tools.
Skill Execution
Platform Skills are orchestrated companion definitions, not a five-tier execution surface. A skill declares its prompt, input and result schemas, model settings, turn and timeout bounds, and the integration or static tools it may call. The Platform API does not currently expose direct, autonomous, browser, or computer_use execution-tier fields.
When a declared tool produces a world-model observation, outbound policy evaluates that event separately. Where the private-preview connector review flow is enabled, a configured destination can stage a specific external write proposal rather than changing the observation's confidence.
See also
World Model for how events and entities work
Clinical Tools for built-in patient lookup, scheduling, and insurance tools
Context Graphs for how states bind workflow tools
Last updated
Was this helpful?