Agent tools & skills
An agent’s model can only write text. Everything else it does, from searching a knowledge store to sending a message or running a command, goes through capabilities you give it. Syntic has three controls for this, each answering a different question:
| Control | Question it answers | Who sets it |
|---|---|---|
| Skills | What is this agent good at? | Developers and above |
| Tool allowlist | Which actions may this agent take? | Administrators and owners |
| Approvals | Which actions must a person sign off first? | Administrators and owners decide each request |
Together they keep an agent as capable as its job needs and no more.
Skills
Skills are packaged capabilities, such as contract review, lead research or ticket triage, that you attach to an agent. They come from a shared catalog.
Browse the catalog
On the AI Agents roster, select Agent Skills. The page lists every skill an AI agent can use, grouped into categories and curated collections, with a count of each at the top.
Agent Skills is a filtered view. Judgment-heavy categories that only make sense for a hired colleague (for example board-level advisory, candidate screening or regulatory interpretation) appear only in the AI staff catalog. Engineering and most operational skills appear in both.
Attach a skill
- Open the skill in the catalog.
- Choose Assign to an agent….
- Search for the agent and select it.
If the project has no agents yet, the dialog offers Create an agent first.
Tool allowlist
Each project runtime has a tool catalog: every tool the runtime can offer, each with a name, description, category and version. Each agent then has an effective list: the tools from that catalog that are switched on for that one agent.
| Contents | |
|---|---|
| Catalog | All tools on the project runtime. The same for every agent in the project. |
| Effective list | The subset one agent can actually call, after its own allowlist is applied. Each entry says whether it is enabled. |
Some tools are marked privileged. They can do more damage if misused and need an administrator to enable.
Who can change it
- Any active member of the project can view the catalog and an agent’s effective list.
- Only administrators and owners can switch a tool on or off for an agent. Each change applies to that one agent and takes effect on the project’s runtime.
Every tool widens what an agent can do on your behalf. Enable only what the task needs, and read a few executions after adding a powerful one.
Approvals
Some actions are too consequential to run unattended. When an agent attempts one, the runtime pauses it and files an approval request instead.
Each request shows which agent asked, a short summary of the action, the details of what it wants to run, who or what triggered it, when it was raised and when it expires.
| Status | Meaning |
|---|---|
pending | Waiting for a decision. |
approved | Allowed; the action goes ahead. |
rejected | Refused; the agent is told and carries on without it. |
expired | Nobody decided in time. Treat it as refused. |
Any member of the project can see the approval queue. Only administrators and owners can approve or reject.
Knowledge, memory and credentials
Three shared resources also shape what an agent can do. They live outside the agent so that several agents, AI staff and workflows can use them:
- Knowledge: document stores the agent can search for answers.
- Memory: what the workforce has learned and kept between conversations.
- Credentials and Variables: encrypted keys for third-party services and named values that workflows and agents can refer to.
Give an agent access only to the stores and credentials its job needs.
Tools in your own code
Console tool settings do not apply to the Syntic API. If you build an agent loop yourself, you describe your own functions in the tools array of each request and run them in your code. You also decide which calls need a human check before running. See Tool calling and the agents quickstart.
Choosing what to allow
- Start with nothing extra. Add a skill or tool only when a real task fails without it.
- Prefer read before write. An agent that can look things up is much safer than one that can change them.
- Route irreversible actions through approval. Payments, deletions and messages to customers are good candidates.
- Keep a separate agent for risky work. Two narrow agents are easier to supervise than one broad one.
- Review after changes. Compare executions before and after you change an agent’s tools.
Related
- Agents on Syntic: the full role table.
- Executions: see each tool call in the traces.
- Organizations & roles.