Agent Configuration Reference - Synthreo Pylon
Configure a Pylon Agent - inspect every editor tab, choose its sandbox image, manage secrets and scoped limits, and distinguish saved configuration from live runs.
Purpose
Section titled “Purpose”Every tab of the Agent editor, with what each field does. To build your first Agent end to end, see Create your first Agent; to put one on a cadence, see Schedule an Agent.
The editor tabs
Section titled “The editor tabs”| Tab | What it controls |
|---|---|
| Overview | Identity and brains: Name, Description, Model (picked from your account’s chat-model catalog), System prompt |
| Tools | What the agent can do per turn: the built-in tool set, plus the coding tools you select and any servers you connect |
| Skills | Instruction packs: toggle catalog skills on; the agent loads their instructions before acting |
| Sandbox | Select the run’s Image and inspect the read-only Preinstalled packages manifest |
| Secrets | The agent’s Secrets section |
| Limits | Guardrails, counted per turn and per resource (table below) |
| Triggers | What starts the agent: Schedule, Manual, Agent-to-agent, Webhook - each addable once. GitHub is a source inside the Webhook box, not a trigger type of its own |
| Config | The canonical configuration document (below) |
| Memory | The Memory section, when its feature gate is enabled |
| Runs | Run history for this agent: Started, Status, Mode, Duration, Completed, Failure reason. Use Monitor → Activity for the cross-agent feed |
Tools: what is on by default, and what you choose
Section titled “Tools: what is on by default, and what you choose”The Tools tab groups what an agent can do as Built-in, Coding, Approval-gated, Planning, Forms, and Chat.
Coding tools are opt-in, not automatic. They are a picker, and a tool you have not selected is invisible to the agent - it will not fail loudly, it will work around the gap or report that it cannot do the thing. If an agent is not doing something you expected, open this tab and check what is actually selected before changing the prompt.
Servers are connected through Connections rather than a capabilities tab.
Sandbox
Section titled “Sandbox”Each run receives an isolated environment on an image Synthreo manages. Use the Image selector to choose from the available images. Preinstalled packages is a read-only manifest; adding a package to an image requires a template-change request.
Limits
Section titled “Limits”Guardrails on how much work the agent may do:
| Field | Caps |
|---|---|
| Max steps | How many actions the agent may take in one turn |
| Token budget | Tokens the agent may consume in one turn - it resets when the agent replies, so it bounds a turn, not a whole run |
| Idle timeout (hours) | How long a run may sit idle before ending |
| Max runs | How many runs the agent may make against one resource - one ticket, one pull request, one issue |
| Token budget (per resource) | Tokens the agent may consume against one resource, across every run it makes on it. Does not reset between runs |
There is no spend or currency cap. Budget in tokens and runs - but be precise about what each pair reaches, because the obvious reading is wrong:
- The per-turn limits bound one turn and reset when the agent replies.
- The per-resource limits do not reset between runs, but a resource is one external thing the agent works on. They bound everything done against that one thing, not the agent’s total.
So nothing here caps the aggregate. An agent that meets a thousand new tickets gets a thousand fresh per-resource budgets. What actually bounds an unattended cadence is how often the trigger fires and how much work reaches it, which makes schedule and input volume part of the budget design rather than separate from it. Watch the spend; do not expect it to be capped.
Set these before enabling a Schedule trigger.
Config: the canonical document
Section titled “Config: the canonical document”The Config tab holds the agent’s whole configuration as a single document: “The canonical config this agent saves. Editing the JSON updates every tab.”
- JSON is authoritative and editable - change it and select Apply, and every tab re-seeds from it.
- YAML is a read-only secondary view for easier reading.
This is also where advanced settings live that have no dedicated tab yet (for example the agent’s step/outcome structure).
Status and going live
Section titled “Status and going live”The header shows the lifecycle state - Enabled with the live revision (“Live: v3”), or that nothing is live yet - alongside Save, Run, and Make draft live:
- Save stores your edits. It does not change what is running.
- Run fires the current draft now (“Run started”). Note that this is gated on edit rights, not on lifecycle state, so a draft can be run by hand while nothing is live.
- Make draft live promotes the saved draft to the live revision.
Enabling a trigger is not the same as making a version live. A trigger fires the live revision, so an agent whose draft has never been made live has nothing for the scheduler to run, however correct the trigger is. This is a common reason a correctly configured schedule never fires.
Related
Section titled “Related”- Create your first Agent
- Schedule an Agent
- DAGs in Pylon - the classic node workflows