Skip to main content
agent_builder is a skill that ships with the Condor assistant. When you ask Condor to create, edit, test, launch, monitor or delete a trading agent, it follows this skill. It works the same in the Workspace chat and in Telegram. The skill has two paths: Condor labels each message with the step it is on, for example [B2 — Discuss], so you can tell where you are. For a short walkthrough, see Build Your First Agent.

​
What it builds

Every agent the skill creates lives in .condor/agents/<slug>/ in your Condor install. The slug comes from the name you give the agent: My Scalper becomes my_scalper. Architecture shows the full folder tree and the format of each file. The skill always creates the agent first, because controllers, routines, skills and loops all hang off its slug.

​
AGENT.md frontmatter

manage_agents writes these keys: The body of AGENT.md is the agent’s own system prompt: who it is and what it doesn’t handle, what it knows, and how it answers.

​
Path A: Build from a description

The skill builds the smallest useful agent first. It doesn’t ask about routines, loops or models up front.
1

A1 — Create the agent

Condor settles two things with you: the agent’s role or domain, and what it is used for. Then it calls manage_agents with action="create" and writes the AGENT.md.
2

A2 — Ask it something

Condor asks the new agent a real question in its specialty with delegate (action="ask") and shows you the answer. If the persona is off, it updates the instructions and asks again. At this point the agent already works as an expert you can hand questions to.
3

A3 — Add routines

One routine at a time. Condor agrees with you on what the routine outputs and why the agent needs it, then hands the job to a background worker (delegate with action="start") that writes and tests it. Condor never writes routine code itself. When the routine is ready, Condor runs it with you (manage_routines run), iterates until the output is useful, and updates AGENT.md so the agent knows to call it and how to read it.The skill stops here unless you want the agent to act on its own.
4

A4 — Add a loop (optional)

Condor designs the loop with you (see Designing the loop) and then follows the loop_builder skill to write loops/<loop>/loop.md, dry-run it and launch it.
Check where a new routine landed. The background worker’s instructions tell it to save routines to Condor’s general library, which the agent can’t run. Open Routines in the Workspace and check that the routine is listed under your agent. If it isn’t, ask Condor to recreate it in the agent’s library (manage_routines create_routine with agent="<slug>").

​
Path B: Build from a folder

Use this path when you already have strategy notes, Hummingbot controllers, configs or scripts and want an agent that runs them. Give Condor the folder’s path. Condor runs on your machine, so any local path it can read works. If you can’t give a path (for example from Telegram on a phone), paste the file contents instead. Nothing is written until you approve the plan in step B3.
1

B1 — Inventory

Condor lists every file in the folder with its size, then reads the text files (.md, .txt, .py, .yml, .yaml, .json). It sorts each file into one of these buckets and shows you the result as a table, with a Not imported list and a reason for each:
2

B2 — Review and discuss

First a mechanical review: each controller’s classes, type and config fields, and any import that is missing; each config’s controller_name and fields; name collisions with controllers other agents already own (a controller’s server copy is shared by name, so a clash must be renamed now); and whether an existing agent should own this instead.Then Condor asks only what the folder doesn’t answer, a few questions at a time, each with a proposed default:
  • One agent or several (default: one)
  • Which configs are real, and the pairs, connector and capital for each. Capital always comes from you, never from a sample config’s total_amount_quote.
  • How vague rules become measurable ones, such as a volatility threshold computed by a routine
  • What should run on its own (the loop decision)
  • Whether to backtest each config or dry-run the loop before going live
  • Whether the winddown policy should differ from the default
3

B3 — Plan

Condor sends one message with the build plan in order: the agent and its when_to_consult, each controller and its styles, each routine and skill, the loop with its frequency, what it may and may never do, its risk limits and winddown, what is not imported, and open questions. It waits for your approval or edits.
4

B4 — Build

In this order, reporting after each step:
  1. Agent: creates AGENT.md with identity, knowledge from your notes, and a Controllers section saying what each controller is for and which style to use when.
  2. Prove it’s alive: asks the agent a question about its own strategy.
  3. Controllers: writes each .py and each style through manage_agent_controllers, writes a CONTROLLER.md if your folder has none, checks status against the server and syncs missing ones. A server copy that differs from yours is never overwritten without showing you the difference and getting your go-ahead. Only the styles you want are uploaded to the server.
  4. Routines: one background job per routine, starting from your original script.
  5. Skills: procedures from your notes, written to the agent’s own library.
  6. Loop: follows loop_builder with the design from B3, runs a Dry Run, shows you the result, and goes live only when you say so.
  7. Winddown: if your policy differs from the default, Condor tells you what to put in .condor/agents/<slug>/shutdown.md. Its frontmatter key is on_kill_switch, set to flatten_all, keep_spot_close_perp or keep_all.
5

B5 — Report

The B1 table again with a Status column (created, in sync, uploaded, pending, not imported), then what runs now, what is pending, and how to monitor it.

​
Designing the loop

An agent can be started without a loop of its own: Condor then creates a generic Default loop driven by AGENT.md on its first start. A loop of its own makes the agent specific and disciplined. A loop doesn’t have to trade. The skill offers the lowest level that fits: For the chosen level, Condor settles with you the frequency (frequency_sec), what the loop may do without asking and what it may only report, the risk limits, the stop condition, and max ticks for the first live run. A controller-based loop never restarts a bot; it stops, archives and redeploys. The risk limits go in the loop’s default_config.risk_limits. Only these keys are accepted: max_position_size_quote, max_open_executors, max_drawdown_pct, shutdown_drawdown_pct, max_drift_quote and max_leverage. See Risk engine for defaults and what each one does.

​
Testing an agent

Every loop can be started in three execution modes. Use them in this order: Dry runs and single ticks write one file each to loops/<loop>/dry_runs/experiment_N.md, not a session. In the Workspace, start them from the agent page’s Start dialog and read the results in the Runs tab. From chat, ask Condor; starting a loop in any mode asks for your approval first.
A Dry Run also refuses routines and run_code. The agent can’t run its own analysis and reads the market with read-only tools such as get_market_data instead. Treat a Dry Run as a check of wiring and reasoning, not of the strategy.
Make sure a market-reading agent can use get_market_data. The skill’s tool advice says an agent that reads markets needs get_prices and run_code and that there is no candle tool. That is out of date: get_market_data returns candles, and it is the only candle tool that works in a Dry Run. If you give the agent a tools allowlist, include get_market_data. An empty allowlist (the default) already includes it.

​
Monitoring and changing agents

Ask Condor, or use the agent page in the Workspace (/agents/<slug>). The skill uses these tools: manage_agents publish copies a local agent into the agents/ folder that ships with Condor, so it can be committed. It is admin only, and the skill mentions it but doesn’t do it unless you ask.

​
Rules the skill follows

  • From a description: role and purpose first, proven with a question. Routines and a loop only when you want them.
  • From a folder: inventory, review, discuss, plan, build. Nothing is written before you approve the plan, and every file is either mapped or listed as not imported with a reason.
  • The agent is created before anything else.
  • It never invents a model key or a server name.
  • Capital comes from you, never from a sample config.
  • Your folder is the source of truth for controllers. A server copy that has drifted is never overwritten without showing you the diff and getting a go-ahead.
  • One routine per background job, and Condor never writes routine code itself. A background job gets 900 seconds by default, so several routines in one job tend to time out.
  • A loop that can trade always has risk limits, is dry-run first, and goes live only when you say so.
  • Background agent runs are unattended and have no approvals, so only hand work to agents you trust.

​
How agents improve themselves

An agent you build doesn’t stay as the builder left it. Every agent, Condor included, reads two playbooks from the shared skill library that tell it how to learn from working with you:

​
self_improve: turn feedback into memory or a skill

When you correct an agent or tell it how you like things done, the agent sorts the lesson into one of three kinds: Memory belongs to one agent and one user: what you teach the Market Making Expert isn’t visible to Condor or to other agents. A rule that should apply to every agent belongs in a shared skill instead, and the agent tells you so. Before creating a skill, the agent lists the skills it already has, so it edits a playbook rather than writing a duplicate. A skill inherited from the shared library is read-only to it. To change one for itself, an agent writes its own skill with the same name, which takes precedence.

​
skill_authoring: how a skill is written

The agent reads skill_authoring before writing a skill. A skill has four parts: Skills are created and edited only through manage_skill, never written to disk by hand: Two more rules from the playbook:
  • Link the routine that does the work. If a skill’s main step is running a routine, the agent links it with references_routine. Reading the skill then reports routine_ok: false if the routine has since been deleted.
  • Default to the agent’s own library. A skill in the shared library lands in every agent’s context on every turn, so only Condor can publish one there (shared=True), and only for a flow that applies to every agent. From the chat, agent="<slug>" writes a skill to that agent’s library instead.
For a skill that keeps missing cases, ask for the skill_optimizer: “optimize the pmm_config_playbook skill”. It runs in the background, tests the skill against generated scenarios, edits it, and repeats for a set number of rounds, notifying you after each one.
You can read and edit what an agent has learned: its skills are under .condor/agents/<slug>/skills/, and you can review its memories with /memory in Telegram. See How Condor Works for how memory is stored and audited.

​
Best practices

Check that the agent, server and exchange are wired up and that the agent’s reasoning makes sense before any live tick. Then do a single Run Once with small capital before starting a loop.
Indicator and scan logic belongs in a routine: deterministic code that returns the same output for the same input. The agent then reads the result instead of computing it in the prompt.
A loop that says which routine to call, how to read its output, and when to act, report or hold gives more predictable ticks than a loose description.
Each loop keeps loops/<loop>/learnings.md, with Market Observations, Execution Notes and Retired Insights sections. Read it in the Playbook tab and edit it when an entry is wrong.