AI Assistance

An agent has two kinds of prompts. The system prompt is the standing brief, set when you create the agent and read on every deployment regardless of which task triggered it. A task prompt is set on each task the agent runs and describes the specific work that task should do; the agent reads it every time the task deploys. The system prompt defines the agent's role and method, while a task prompt defines what one particular task is trying to do.

Write the system prompt like a job description. List the steps the agent should work through, the tools it should use at each step, and what counts as success. Think of it as teaching the agent how to approach the problem, not just what to do. Spell out the order to gather evidence, what to check at each step, and how to decide when the work is done.

A well-written system prompt names the inputs the agent should look at, the constraints it should respect, the output it should produce, and any caps on how much work to do. Keep the system prompt focused on the agent's role. Put task-specific instructions into each task's prompt instead, and assume the agent has no memory of prior deployments.

To make one system prompt work across project languages, wrap language-specific instructions in <python> and <csharp> tags. The agent only sees the contents of <python>...</python> when running on a Python project, and only sees <csharp>...</csharp> when running on a C# project. This keeps the active context free of rules that don't apply to the current run.

<csharp> C# prompt details </csharp>
<python> Python prompt details </python>

Context is everything the model sees when it runs, including the system prompt, the task prompt, results from tool calls, and any data passed in. Every word counts against the model's context budget. Long contexts cost more, slow the model down, and crowd out the actual reasoning it needs to do. The goal is to give the agent the minimum it needs to do the work well.

Keep the system prompt tight. Focus on the parts that change outcomes like the specific steps, the named tools, the hard constraints, and the format of the output. Avoid motivational language, repeated reminders, and paragraphs of background the agent doesn't need.

Keep task prompts focused on the specific work for this run. Include the inputs the agent needs and the constraints unique to this deployment, and don't repeat what is already in the system prompt.

Tools are the capabilities you grant an agent. For example, reading project files, running notebook cells, creating backtests, fetching recent news, and sending notifications are all tools you can enable. Each tool you enable expands what the agent can do and what it can choose between when planning a step.

Be selective about which tools to enable for an agent. The model considers every available tool at every step, so an agent with twenty tools is slower and more likely to misroute work than one with the four tools it actually needs. Withholding tools matters as much as enabling them.

When you write the system prompt, name the tools the agent should use at each step. This tells the model which capability you intended for which task and reduces the chance it picks a related-looking tool that isn't the right tool for the job.

By default, Agents run using our free QuantConnect Meta Agent. It requires no setup and is the right choice when you want the agent working without bringing your own LLM API key.

Organizations with a paid Agent Node can supply an API key from an LLM provider of their choice. With your own provider, you can select a specific model, configure the reasoning effort, the maximum number of turns the agent takes per deployment, and the tool selection policy. For information about how to get a key from each provider, see Bring Your Own Key.

A structured output is a JSON schema that constrains what the agent returns. When you specify one, the agent produces a response that conforms to the schema instead of free-form prose. This is the difference between an agent that says "the residuals look stationary, with a p-value around 0.03" and one that returns {"stationary": true, "p_value": 0.03}.

Use a structured output when something downstream consumes the result. Some examples include another agent in a chain, a custom API response handler, or just a human who needs to quickly scan for the key insight. Without a schema, the next step has to parse prose, which fails the moment the wording shifts.

To use one, define the JSON schema in the Output Schema field of the agent configuration. Keep the schema as flat as the next step needs. Nested schemas are valid but add room for the agent to drift from the shape you wanted.

For example, the schema that produces the preceding stationarity output would look like this:

{
  "type": "object",
  "properties": {
    "stationary": {
      "type": "boolean",
      "description": "Whether the residuals pass an ADF stationarity test."
    },
    "p_value": {
      "type": "number",
      "description": "The p-value from the ADF test."
    }
  },
  "required": ["stationary", "p_value"]
}

You can assign each agent to a single stage of the Research Pipeline. When a card lands in that stage on the Research Pipeline, the assigned agent automatically deploys and starts working on the project. In the agent configuration, you can choose which stage to assign the agent to, or choose to leave it unassigned and just deploy it manually when you want it to work. The predefined Agents come with their stage already set. For example, the Backtest Agent is assigned to the Backtest stage of the Research Pipeline.

You can configure an agent to involve other agents in its work. Chained orchestration links agents in a fixed sequence. The first agent runs the task, its output is passed to the next agent as input, and so on until the chain ends. Use a chain when the work breaks naturally into stages that each have a different specialist, for example an Ideas Agent feeding a Research Agent feeding a Backtest Agent. For details on how the sequence executes at deployment time, see Chained Agents.

Callable orchestration exposes other agents as tools the assigned agent can invoke when it needs them. This is similar to a regular tool call, except the "tool" is another agent. Use callable orchestration when the path through the work is not known in advance. An agent might call a Research Agent in one deployment and a Live Monitoring Agent in another, depending on what it finds. For details on how callable agents behave at deployment time, see Callable Agents.

To view all the Agents in your organization, log in to the Algorithm Lab and then, in the left navigation bar, click Organization > Agents.

We provide several built-in agents for common community goals. You can customize these to your project goals by creating a custom agent. By default, Agents run on the free QuantConnect Meta Agent. To use a different LLM, set your own API key when you create the agent and configure the reasoning effort, max turns, and tool choice.

Follow these steps to add Agents to your organization:

1. Log in to the Algorithm Lab.
2. In the left navigation bar, click Organization > Agents.
3. Click Add Agent.
4. Fill out the New Agent form.
5. Click Create Agent.

Follow these steps to update the Agents in your organization:

1. Log in to the Algorithm Lab.
2. In the left navigation bar, click Organization > Agents.
3. Click an Agent.
4. Edit the Agent configuration.
5. Click Save Changes.

Follow these steps to delete an Agent in your organization:

1. Log in to the Algorithm Lab.
2. In the left navigation bar, click Organization > Agents.
3. In the row of the Agent that you want to remove, click Delete.

A custom skill is a reusable set of instructions you add to your organization so your agents apply your own expertise and conventions instead of generic defaults. A skill might capture your risk limits, a preferred indicator workflow, or the house style every strategy should follow. Custom skills live inside the reserved .agent folder of your organization's Object Store. The folder layout looks like this:

.agent/
└── skills/
    ├── risk-limits/
    │   └── skill.md
    └── earnings-screen/
        ├── skill.md
        └── reference.md

The agents don't load every skill up front. An agent scans your available skills and loads the relevant one only when a task calls for it, so a large library of skills never crowds its context. Every agent in your organization can use your custom skills.

Custom skills use the standard Claude skill structure. For examples, see the skills in the Documentation repository. The skill.md file starts with a YAML frontmatter block that gives the skill a name and a description, followed by the instructions in Markdown. The description is how the agent decides when to use the skill, so describe the situations when the agent should use it. The folder can also hold supporting files that the instructions reference.

For example, the following skill defines risk limits for strategies:

---
name: risk-limits
description: The position-sizing and stop-loss rules every strategy in this organization follows.
---

# Risk Limits

When you build or modify a strategy, enforce these rules:

- Never allocate more than 10% of the portfolio to a single position.
- Attach a stop-loss order at twice the 20-day ATR below the entry price.
- Keep gross leverage at or below 1.5.

Manage these files like any other Object Store data. Create the .agent / skills / subfolders and upload one skill.md per skill. For information on uploading files to the Object Store, see the documentation for the Algorithm Lab, CLI, or API.

Memory lets an agent remember facts about you and your organization across conversations and projects, so you don't restate the same context every time you start a task. You might record your default data resolution, the benchmark you compare against, or the asset classes your team trades.

Custom memory is a single .agent / memories / memory.md file in your organization's Object Store. It is plain Markdown, so you can write the facts as a simple list or as short notes. For example, memory might look like this:

- Default to hourly resolution for equity strategies unless asked otherwise.
- Benchmark all backtests against SPY.
- The team trades US Equities and Equity Options only.

Agents that use memory load this file automatically at the start of each run, so your facts are always in context without any action from you. When you edit memory.md by hand, the change takes effect the next time an agent runs. Agents also keep the file current on their own, recording new facts they learn as they work, so their memory builds up over time.

A custom template is your own project scaffold that you and your agents can start new projects from, so a common strategy skeleton is ready to use instead of a blank file. Custom templates live inside the .agent / templates / directory of your organization's Object Store. The directory layout looks like this:

.agent/
└── templates/
    ├── python/
    │   ├── templates.json
    │   └── psar-trailing-stop/
    │       ├── main.py
    │       └── research.ipynb
    └── csharp/
        ├── templates.json
        └── psar-trailing-stop/
            ├── Main.cs
            └── Research.ipynb

Templates are grouped by language in a python or csharp subfolder. Each language folder holds a templates.json file that registers the templates, plus one subfolder per template that holds the project files. Each entry in the templates.json file has a name, folder, description, and tags array. The folder must match the subfolder that holds the project files, and the agent reads the name, description, and tags to help it pick the correct template. Write asset class tags in PascalCase, matching the SecurityType values (for example, Equity, Future, Option, or Crypto). Other tags are free-form. For example, the .agent / templates / python / templates.json file might contain the following JSON:

{
    "templates": [
        {
            "name": "Parabolic SAR Trailing Stop",
            "folder": "psar-trailing-stop",
            "description": "Trades SPY long-only with Parabolic SAR providing dynamic trailing-stop levels and re-entries.",
            "tags": ["Equity", "indicators", "parabolic-sar", "trailing-stop"]
        }
    ]
}

Each template subfolder holds an ordinary project, the same as any project you create. A Python template under .agent / templates / python / has a main.py file. A C# template under .agent / templates / csharp / has a Main.cs file. A template can also include a research notebook (research.ipynb for Python or Research.ipynb for C#) and any other files the project needs. For examples, see the project-templates directory in the Documentation repository.

Manage these files like any other Object Store data. For information on uploading files to the Object Store, see the documentation for the Algorithm Lab, CLI, or API.

The following example agent configurations demonstrate some common use cases.

Example 1: News Summarizer

This example agent reads the latest oil news once a day and emails you a summary.

System prompt:

Read the financial news from the past 24 hours about crude oil, OPEC, and US energy policy. Filter to the items that materially affect the oil price. Write a summary of three to five bullets, each one sentence, naming the event and why it matters. Send the summary by email.

Tools:

• financial_data_news_articles
• financial_data_web_get
• send_email_notification

Schedule: Daily 30 minutes before US market open.

Exmaple 2: ML Trainer

This example agent runs a research notebook daily, evaluates the fit, and saves the model to the Object Store if it passes a quality bar.

System prompt:

Execute the model_training notebook in the current project. Read the fit metrics from the last cell's output. If the R-squared is above 0.4 and the residuals pass an ADF stationarity test, serialize the trained model and save it to the Object Store under the key "latest_model". If the fit fails either check, do not overwrite the existing model and send an email summarizing the failure.

Tools:

• jupyter_read_notebook
• jupyter_execute_notebook
• jupyter_read_cell
• object_store_set
• send_email_notification

Schedule: Daily after US market close.

Example 3: Optimization Stability Monitor

This example agent runs a weekly optimization on the project, measures how much the Sharpe ratios vary across the parameter combinations, and sends a Telegram alert only when that variation has grown enough to suggest the strategy is becoming sensitive to its parameters.

System prompt:

Run an optimization on the current project. Read the resulting backtests and compute the standard deviation of their Sharpe ratios across all the parameter combinations. Compare to the previous standard deviation stored in the Object Store under the key "param_stability_std". If the new value is more than 30% above the previous, classify the parameters as less_stable and send a Telegram alert with the structured diagnosis. Otherwise, classify as stable and do not send any notification. Save the new standard deviation to the Object Store either way.

Tools:

• create_optimization
• read_optimization
• object_store_get
• object_store_set
• send_telegram_notification

Schedule: Weekly on Sunday at noon.

Output schema:

{
  "type": "object",
  "properties": {
    "verdict": {
      "type": "string",
      "enum": ["stable", "less_stable"]
    },
    "current_sharpe_std": {
      "type": "number",
      "description": "Standard deviation of Sharpe ratios across this week's optimization."
    },
    "previous_sharpe_std": {
      "type": "number",
      "description": "Standard deviation from the previous run, read from the Object Store."
    },
    "recommendation": {
      "type": "string",
      "description": "What action to take, in one sentence."
    }
  },
  "required": ["verdict", "current_sharpe_std", "previous_sharpe_std", "recommendation"]
}