Built-in Tools
Built-in tools are the agent's core cognitive layer: always available, never tied to a specific integration. They handle planning, memory, graph querying, arithmetic, formatting, and output rendering. Every agent needs these regardless of which molecules are connected.
You never call built-in tools directly. The agent selects and invokes them automatically. Understanding what they do helps you read a run and spot problems early.
The live plan
For any multi-step task, the agent declares a plan up front and checks off each step as it executes. The plan appears as a live checklist in the task detail view.
Screenshot needed: Task detail page mid-run, showing the Plan panel: three or four steps with the first two marked done (green check), one in progress (animated spinner), and the rest pending (gray). Each step has a short description and the tool the agent expects to use.
:::
The plan is functional, not decorative. It surfaces intent before action, so a wrong-looking step is readable immediately. That's far easier than parsing raw tool-call JSON after the fact.
Memory
A saved agent has a persistent scratch pad scoped to that agent. The agent can write and read key-value notes across runs.
| Use case | Example note |
|---|---|
| Resuming where it left off | last_synced_opportunity: 0065f00001abc |
| Carrying a user decision forward | escalation_threshold: page on SLA under 2h |
| Accumulating a running tally | tickets_resolved_this_week: 14 |
Memory is per-agent. Two agents in the same environment do not share notes. Chat sessions (no saved agent) have no memory at all.
The dashboard surfaces the agent's current memory on its detail page, with per-key timestamps and a clear action.
Screenshot needed: Agent detail page Memory tab: a small table of keys with a preview of each value, the last-touched timestamp, and a Clear action per row.
:::
Graph queries
Every agent can query the knowledge graph through built-in tools: search by type or attribute, fetch a single entity by ID, traverse relationships, or retrieve history. These are typically the first tools an agent calls: finding what to work on before reaching for integration-specific tools.
Graph queries drive late tool disclosure. When the agent searches for Salesforce accounts, the platform surfaces Salesforce tools on the next turn. Search for Zendesk tickets and you get Zendesk tools. This prevents the agent from being confused about which create_ticket tool to call when both Zendesk and Intercom are connected.
Utility tools
A small set of utility tools handles tasks where LLM reasoning is unreliable on its own.
| Tool | What it does |
|---|---|
| Aggregate | Groups, counts, sums, and deduplicates records from prior tool results. More reliable than asking the model to count in its head. |
| Calc | Deterministic arithmetic and unit conversion. Floats don't drift; tax math is exact. |
| Display | Renders results as a structured table or list that the dashboard formats cleanly, rather than Markdown the model writes by hand. |
The agent picks these up automatically. A tidy table in a run result instead of a bullet-point wall means display was called.
PDF reports
When an agent produces a report (a quarterly review, compliance snapshot, or owner statement) it can pass formatted HTML to render_pdf. The dashboard attaches a downloadable PDF to the task result.
Screenshot needed: Task result panel showing a generated PDF artifact card: file name, page count, Download and Share link buttons.
:::
PDF output is useful for anything you need to email, archive, or hand to someone outside SixDegree. The file is attached to the task record and retrievable later.
Skills
Skills are pre-built workflow recipes shipped by molecules or the platform. They specify which tools to call and how to format the result. They're valuable when the output format itself matters (compliance reports, MBR documents, dashboards with a defined layout).
When the agent's goal matches a known skill, it loads that recipe and follows it. The result is consistent formatting across every run, without any configuration on your part.
Skills are discovered automatically. You do not configure which skill to use; the agent searches the skill library and selects the closest match.
What is not built in
If a tool talks to an external service, it lives on a molecule, not in built-ins.
| Tool | Molecule |
|---|---|
salesforce_get_activities, salesforce_log_call | Salesforce |
zendesk_post_reply, zendesk_get_open_tickets | Zendesk |
pagerduty_escalate | PagerDuty |
netsuite_get_invoices | NetSuite |
github_create_issue | GitHub |
Built-ins cover the agent's cognition: planning, memory, graph access, and output formatting. External actions are always a molecule's responsibility.
If you see a tool call failing that looks like it should be built in, check whether the relevant molecule is installed and running. Graph tools and formatting tools are built in; anything that calls an external API is not.
Next steps
- Agents: what invokes built-in tools and how agent runs are structured
- Tools: molecule-provided tools and the entity-binding model
- Molecules: where integration tools come from
- Knowledge Graph: the graph the agent queries through built-in tools
- Tasks: how to read a run and interpret the plan, tool calls, and result