Agents on Syntic

An agent is an Amara model that has been given a job, a set of capabilities and a place to run. A single API request answers one message and stops. An agent keeps going: it reads its input, decides what to do, uses a tool, looks at what came back and repeats until the task is finished or it needs a person.

Syntic gives you two ways to get that behaviour:

	Console agents	Your own agent loop
What you build	An agent that lives in a Syntic project and runs on the project’s own runtime.	A program that calls the Syntic API in a loop and runs your functions between calls.
Where you set it up	The Syntic Console, under AI Agents.	Your code, using POST /v1/chat/completions with tools.
Who talks to it	People on connected channels, your team in the Console, workflows.	Whatever your application connects it to.
How you watch it	Executions, Live activity and session transcripts in the Console.	Your own logs, plus the x-syntic-request-id header on every response.
Access	Signed-in Console users, by role.	Any sk_live_ API key.

When to use which

Choose a Console agent when:

• the agent should answer people on a messaging channel such as Telegram, Slack or WhatsApp;
• non-developers on your team need to create, adjust or supervise it;
• you want run history, traces and approvals without building them yourself;
• the agent should share knowledge, memory and skills with the rest of your Syntic workforce.

Choose your own loop when:

• the agent is part of your product and must run inside your infrastructure;
• you need full control over which functions exist and how their results are checked;
• requests come from your backend with an API key, not from a signed-in person.

Key ideas

Organization and project. Everything in the Console belongs to an organization, and agents belong to a project inside it. Members, roles and billing belong to the organization; agents, sessions, channels and the runtime are per project.

Runtime. Each project that runs agents gets its own isolated runtime node. The node hosts the project’s agents, holds their sessions and connects to channels. Until a runtime is deployed, agents show Not deployed and cannot take work. See Deployment.

Agent. A focused worker with instructions, a personality, a content policy, an Amara model and a list of skills and tools. Each agent has a short Agent ID shown on its Overview tab.

Skills and tools. Skills are capabilities picked from the Agent Skills catalog and attached to an agent. Tools are the actions the runtime lets an agent perform; each agent has its own allowlist. Some actions wait for a person to approve them. See Tools & skills.

Channel. A connection between the project’s runtime and an outside messaging service. See Channels.

Session. One running conversation between an agent and one contact on one channel. See Sessions.

Execution. The stored record of one run, with its input, output, final state and step-by-step traces. See Executions.

How a Console agent handles a task

1. A message arrives on a connected channel, or someone starts the agent from the Console or a workflow.
2. The runtime opens (or continues) a session for that contact and starts an execution.
3. The agent’s model reads the conversation and its instructions and decides on a next step.
4. If it needs a tool, the runtime checks the agent’s allowlist. Allowed calls run; calls that need sign-off wait in the approval queue.
5. Each step is written to the execution as a trace: what kind of step it was, its input, its output and any error.
6. The agent replies on the channel. The execution closes with a final state, such as finished or error.

You can follow steps 3 to 6 live from the agent’s Live activity panel and review them later under Executions.

AI agents and AI staff

The Console has two kinds of worker built on the same foundation:

	AI agents	AI staff
Purpose	Built and deployed for one repeatable function: research, lead scoring, drafting content, answering a support channel.	Hired into a role, such as sales lead or support manager, and talked to like a colleague.
How you create one	Ask the project’s IT Manager (a built-in member of AI staff) in a conversation.	Hire AI Staff.
Console area	AI Agents	AI Staff

Knowledge, Memory, Credentials and Variables are shared by both. These pages cover AI agents.

Agent status

Each agent card shows one of these states:

Status	Meaning
Running	Deployed and able to take work.
Pending	Starting up.
Idle	Stopped. It keeps its configuration but takes no work.
Error	Something needs attention. Open the agent and check its Logs tab and recent executions.
Not deployed	The agent is marked as running, but the project has no runtime yet. Deploy one first.

You can narrow the roster to one status and limit it to the current project or shown across all projects.

Who can do what

Action	Developer	Administrator, Owner
View agents, sessions, executions, tool lists and the approval queue	Yes	Yes
Create and edit agents, attach skills	Yes	Yes
Connect or disconnect channels	Yes	Yes
Turn individual tools on or off for an agent	No	Yes
Approve or reject a pending action	No	Yes
Deploy, restart, suspend, stop or start the project runtime	No	Yes
Terminate or delete executions	No	Yes

Only active members of the organization have access. Roles are explained in Organizations & roles.

Cost

An agent loop you write yourself is billed exactly like any other API traffic: tokens count toward your plan allowance, then usage credits if they are enabled. See Usage & cost and Pricing.

Console agents also run on Amara models. The Usage page in the Console’s Activity group shows what they consumed.

Next steps

• Quickstart: create a first agent, or write a first agent loop.
• Deployment: give a project its runtime.
• Tools & skills: decide what an agent may do.
• Executions: follow and debug runs.