How Condor Works

The assistant you talk to on the Agents page is not a hard-coded chatbot. Condor is itself an agent, built from the same parts as the agents you create, and every part is a plain file you can open. Its definition ships with Condor under agents/condor/. What your install writes for it, such as its memory of you and any skill it creates, goes under .condor/agents/condor/:

agents/condor/                         # shipped with Condor
├── AGENT.md                           # its brain: identity, tools and rules
└── skills/                            # its own playbooks
    ├── agent_builder/SKILL.md
    ├── diagnose_solana_token_decimal_mismatch/SKILL.md
    └── log_analyzer/SKILL.md

.condor/agents/condor/                 # written by your install
├── skills/                            # skills it creates or edits
└── store/
    └── user_<id>/                     # one memory store per user
        ├── MEMORY.md                  # one-line index, injected into every session
        ├── memories/                  # one file per memory
        └── audit.log                  # every write and delete, timestamped

When both places have the same file, the one under .condor/ wins. Agents you build with Agent Builder get the same layout under their own slug. See Agent Architecture for the full folder structure.

AGENT.md: the brain

AGENT.md is the agent’s system prompt with a short frontmatter header:

---
name: Condor
description: General trading assistant
agent_key: claude-acp:sonnet
---

# Condor — Trading Assistant

You are Condor, a trading assistant. ...

agent_key sets the model it runs on by default. The body does three jobs:

Names its tools. They come from two MCP servers: mcp-hummingbot (market data, portfolio, executors, bots, DEX tools) and condor (notifications, routines, agents and loops, servers, memory, skills and delegate). For the full list, see MCP Tools. Adding or removing exchange keys is not one of them: you manage keys yourself in Settings → Keys and Wallets.
Sets how it routes work (next section).
States its rules: lead with the answer, ask for confirmation before orders, swaps and LP changes, keep tool chains short, and don’t read source code unless asked.

A coordinator, not a tool-caller

Before any tool call, Condor runs a routing check:

Does a skill match? Its skill index is in context as [SKILLS]. If a playbook covers the request, Condor reads it and follows its steps.
Does a domain agent match? The [AGENTS] index lists your agents. Domain work goes to the specialist, which has the domain’s tools and memory.
Only then does it use raw tools.

It hands work to another agent with delegate, which has two shapes:

Call	What happens	Use it when
`delegate(action="start", ...)`	The other agent runs in a detached background session. Condor tells you the task is running and ends its turn; you are pinged when it finishes. With `on_complete="resume"`, Condor gets the result in a new turn and carries on.	The default whenever you are waiting: a deployment, a research task, anything slow
`delegate(action="ask", ...)`	Blocks and returns the other agent’s answer as text	Condor needs a quick answer as a step in its own reasoning. It is also the only option for an agent running unattended.

delegate also has list, get and stop to check on or cancel a delegation. In Telegram, /delegations lists them; on the Workspace they appear in the chat’s Tasks list. One rule is absolute: Condor never writes routine code in the chat. Creating, editing or fixing a routine is always delegated to a background copy of Condor itself (delegate(action="start", agent="condor", ...)), which follows the routine_cookbook playbook, writes the routine and tests it before reporting.

Skills: how it operates

A skill is a playbook: when to use it, and the steps. Each one is a folder with a SKILL.md:

---
name: diagnose_solana_token_decimal_mismatch
description: Find and explain why a Solana token shows the wrong amount or price in
  the portfolio
when_to_use: User says a token amount or value in the portfolio looks wrong — too
  large, too small, or inconsistent with what their wallet shows
created: '2026-09-01T20:33:20Z'
source: reflection
---

1. Fetch the portfolio overview and note the suspect token's raw amount and value_usd.
2. Call run_code to query the gateway for that token's metadata, especially `decimals`.
...

The source field says where a skill came from:

`source`	Meaning
`builtin`	Shipped with Condor
`chat`	Written with `manage_skill` during a conversation
`reflection`	Proposed by Condor after reviewing a finished conversation, and accepted by a person before it was added

Condor’s own skills

Skill	When it applies	Source
`agent_builder`	You want to create, edit, dry-run, launch, monitor or delete a trading agent, including turning a folder of controllers and notes into one. See Skill: Agent Builder.	`builtin`
`log_analyzer`	Any question about bot, executor or Gateway logs and errors. It runs the `logs_summary` routine rather than reading logs call by call.	`builtin`, `references_routine: logs_summary`
`diagnose_solana_token_decimal_mismatch`	A Solana token’s amount or value in the portfolio looks wrong	`reflection`

references_routine means the skill’s executable part is a routine: the skill says when, the routine does what. If the routine no longer exists, reading the skill reports routine_ok: false instead of running nothing.

The shared library

agents/_shared/skills/ holds playbooks that every agent reads, Condor included. An agent’s own skill with the same name takes precedence. The shipped shared skills are:

Area	Skills
Building and running agents	`agent_framework`, `loop_builder`, `operate_your_loop`, `controller_sources`
Skills and self-improvement	`skill_authoring`, `skill_optimizer`, `self_improve`
Routines, data and charts	`routine_cookbook`, `market_data_with_code`, `execution_data_with_code`, `charting`, `backtest_flow`
Trading decisions	`directional_position`, `dca_into_position`, `run_a_grid`, `open_lp_position`, `recover_orphaned_position`
Connectors	`verify_connector_support`, `hyperliquid_tokenized_perps`

Only Condor can publish to the shared library, with manage_skill(..., shared=True). A shared playbook lands in every agent’s context, so it has to read correctly from every seat. A skill that belongs to one agent is written to that agent instead, with manage_skill(..., agent="<slug>"). Skills are advice, not permission: an action a playbook describes still goes through the normal confirmation for orders, swaps and LP changes.

Memory: what it knows about you

Skills are how the agent works, the same for every user. Memory is what it knows about you. It is kept per agent and per user: Condor’s memory of you lives in .condor/agents/condor/store/user_<id>/. Memory is not shared between agents. Each trading agent keeps its own memory of you in its own store, .condor/agents/<slug>/store/user_<id>/. What you tell the Condor chat isn’t visible to your trading agents, and the other way round. MEMORY.md is the index, one line per memory. It is injected into every chat session as [USER MEMORY], so Condor starts each conversation knowing the headline of everything it has saved. The detail is in memories/<name>.md, read when needed. For example, a preference saved with manage_memory(action="write", ...) is stored like this:

---
name: report_in_usd
description: User wants P&L and balances reported in USD
type: preference
created: '2026-10-01T09:12:00Z'
source: chat
---

Always report P&L and balances in USD, even for pairs quoted in USDT.

Each memory is one fact, with a type of preference, fact, feedback or reference. Condor saves only what is new and stable about you, not details of the current conversation. After a conversation has been idle for 30 minutes, a background pass can also read it back and save memories from it; set CONDOR_REFLECTION=off to turn that off. Every write and delete is appended to audit.log. You can review and delete memories with /memory in Telegram, which shows a section per agent, or ask Condor to run manage_memory(action="audit").

Memory vs. skills

	Memory	Skills
Holds	Facts about you	Procedures for the agent
Scope	Per agent, per user	Per agent, the same for every user (plus the shared library)
Injected as	`[USER MEMORY]` index	`[SKILLS]` index
Written when	You state a preference or correct it, or a stable fact comes up	It works out a reusable procedure
You control it with	`/memory`, the audit log	The files under `skills/`, or asking it

Learn more

Skill: Agent Builder: the playbook Condor follows to build new agents with this same anatomy
Agent Architecture: how agents are laid out and run
MCP Tools: every tool Condor and its agents can call
Agent Loops: watching an agent work

Condor

Getting Started

Condor Agents

Running and Building Agents

Workspace Pages

How Condor Works

AGENT.md: the brain

A coordinator, not a tool-caller

Skills: how it operates

Condor’s own skills

The shared library

Memory: what it knows about you

Memory vs. skills

Learn more

​AGENT.md: the brain

​A coordinator, not a tool-caller

​Skills: how it operates

​Condor’s own skills

​The shared library

​Memory: what it knows about you

​Memory vs. skills

​Learn more

AGENT.md: the brain

A coordinator, not a tool-caller

Skills: how it operates

Condor’s own skills

The shared library

Memory: what it knows about you

Memory vs. skills

Learn more