> For the complete documentation index, see [llms.txt](https://docs.amigo.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.amigo.ai/agent/platform-functions.md). # Platform Functions {% hint style="info" %} **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](https://docs.amigo.ai/developer-guide/platform-api/functions) for endpoint details. {% endhint %} 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. ```mermaid flowchart LR agent["Agent mid-conversation"] --> fn{Function Type} fn --> sql["SQL\n(query live + analytical data)"] fn --> ai["AI\n(classify, extract, summarize)"] fn --> py["Python\n(custom logic)"] fn --> tvf["Table-valued\n(multi-row results)"] sql --> result["Structured result\nback to agent"] ai --> result py --> result tvf --> result ``` ## 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_`, 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_`, 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: | Type | What It Does | Example | | ---------------- | ------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- | | **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. {% hint style="info" %} **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) {% endhint %} 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_`) 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](/agent/clinical-tools.md) and the [World Model](/data/world-model.md) 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: ```yaml tool_call_specs: - tool_id: fn_entity_confidence - tool_id: wsq_appointment_history additional_instruction: "Look up the patient's appointment history when relevant" ``` 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](/reference/agent-forge.md) - see the [developer guide](https://docs.amigo.ai/developer-guide/platform-api/functions) 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](/reference/agent-forge.md) provides function management commands: ```bash forge platform function list forge platform function catalog forge platform function register --file function.json forge platform function test --input '{"argument": "value"}' forge platform function query --sql 'SELECT ...' forge platform function sync forge platform function delete ``` ## How Tool Types Relate The platform has three complementary tool types. Each serves a different purpose: | | Platform Functions | Actions | Skills | | -------------------- | --------------------------------------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------- | | **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. {% hint style="info" %} **See also** * [World Model](/data/world-model.md) for how events and entities work * [Clinical Tools](/agent/clinical-tools.md) for built-in patient lookup, scheduling, and insurance tools * [Context Graphs](/agent/context-graphs.md) for how states bind workflow tools {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.amigo.ai/agent/platform-functions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.