Building Signals That Trade Themselves: Governed AI Agents in Production

1. The problem: AI cannot work with undocumented expertise

Man Group is one of the world’s largest active investment managers. Their quants have spent decades building a particular way of working: specific data conventions, backtesting protocols, risk constraints, naming schemes. That expertise lives in the heads of senior researchers and in thousands of lines of internal tooling.

When Tushara Fernando’s team set out to give Claude Code to their ~750 developers and quants, the first challenge was not the model — it was knowledge transfer at scale. A capable AI that doesn’t know how Man Group’s quants think is no more useful than a brilliant new hire on day one: technically skilled but contextually blind.

The naive approach — dump documentation into a system prompt — doesn’t work in a regulated investment firm. Prompt-stuffing is brittle, hard to audit, and has no governance story. Instead, the team built two foundational layers that solved the knowledge transfer problem properly:

1. A skills framework — modular, versioned AI capabilities that encode institutional knowledge
2. A core data layer — a governed interface between Claude and production datasets

Everything that followed, including trading signals researched and proposed by AI running real capital, was built on top of those two foundations.

2. The skills framework: packaging expertise as composable capabilities

A skill in Man Group’s framework is a self-contained unit of capability: one coherent piece of quant workflow encoded as a reusable, version-controlled module that Claude Code can invoke.

Think of skills like functions in a well-designed library. Each skill has:

• A clear name and purpose (“backtest a momentum signal”, “run risk decomposition”)
• Typed inputs and outputs that make them composable
• Embedded domain knowledge — the conventions, defaults, and constraints a senior quant would apply
• A governance status — draft, reviewed, or approved — before they can touch real systems

After building the first few skills manually with senior researchers, the team noticed a compounding effect: Claude could start discovering and proposing new skills by pattern-matching against the existing library. The skills framework became self-extending.

By the time of this talk, Man Group had deployed 100+ skills across research, risk, and operations workflows. The number matters less than what it represents: a structured transfer of decades of quant knowledge into a form that AI can reliably use — and that compliance can audit.

Why modularity beats monolith

A monolithic “do quant research” prompt is opaque, impossible to audit, and fails unpredictably. Skills are the opposite: each is small enough to fully understand, test in isolation, and approve specifically. A compliance officer reviewing “run_backtest_v2” knows exactly what it does and what guardrails are baked in. They can say yes to that specific skill without having to say yes to unbounded AI access.

3. The core data layer: structured access over free-form queries

The second foundational component is the core data layer — the interface between Claude and Man Group’s production data. This is where many AI projects go wrong: they give the model direct database access and free-form query capability. In a regulated firm, that is a non-starter.

Man Group’s core data layer does the opposite:

• No free-form SQL. Claude calls typed functions (“get daily returns for fund X over date range Y”) that are implemented, tested, and reviewed by engineers. The model never constructs raw queries against production databases.
• Row-level permissions. Each data access call respects the same permission model as human analysts. Claude cannot access data a researcher wouldn’t be allowed to touch directly.
• Full audit trail. Every data request is logged: what was requested, by which skill, in which session, by which user. This is the audit trail that compliance needs to say yes.
• Semantic naming. Functions are named in the language of the quant domain, not the database schema. This matters: Claude reasons better over get_factor_exposure(strategy, factor) than over table joins.

The data layer is what turns a capable model into a trustworthy agent. Without it, you have AI that might do the right thing. With it, you have AI that can only do the things your organization has explicitly sanctioned.

4. The signal→action pipeline and where humans stay in the loop

With the skills framework and data layer in place, Man Group built increasingly autonomous research pipelines. The progression followed a deliberate autonomy ladder — each rung adding more agent responsibility while preserving human checkpoints where they matter most.

The autonomy ladder

Rung 1 — Assisted research. Claude surfaces candidate signals from data. A quant reviews every output before anything moves forward. Useful but not yet transformative.

Rung 2 — Drafted proposals. Claude runs fetch → backtest → risk decomposition as a sequence, then produces a structured research report. A quant reviews the report, not the raw outputs. Higher leverage: one human hour covers ten times the research surface area.

Rung 3 — Proposed signals. Claude identifies a signal, backtests it, checks it against risk constraints, and submits it as a formal proposal — complete with the documentation a quant would write. The human checkpoint is now at the approval gate, not in the research loop.

Rung 4 — Signals in production. Approved signals run real capital. The agent that proposed them is not involved in execution; execution is handled by existing, audited systems. AI’s job ends at the proposal; human engineers own deployment.

At the time of this talk, Man Group had reached rung 4. Trading signals researched, backtested, and proposed by AI are running real capital at one of the world’s largest hedge funds.

The non-negotiable checkpoints

The autonomy ladder works because human oversight is concentrated at the moments where the stakes are highest, not distributed evenly across every step:

1. Skill approval — before any capability can be used in production
2. Signal proposal review — before any backtested signal is approved
3. Deployment decision — before any signal runs real capital

Steps in between — data retrieval, backtest execution, risk decomposition, report drafting — are fully automated. This is the right inversion: automate the tedious, high-volume work; preserve human judgment for the irreversible decisions.

5. Scaling the framework: 750 developers and the governance model

Deploying to ~750 developers and quants at a regulated firm required solving a governance problem that goes beyond technical design. The skills framework had to produce a credible answer to the question: “How do we know what the AI is doing?”

The governance model

Man Group’s answer has three components:

Versioned skills as the unit of governance. Every capability Claude can invoke has a version number and a status. Draft skills can be used in sandboxed research. Reviewed skills can be used by individuals. Approved skills can be used in production pipelines. Compliance reviews skills, not prompts — a far more tractable problem.

Separation of research and execution. The AI pipeline ends at the proposal. Execution happens in existing, independently audited trading systems. The AI never touches the execution layer. This boundary is structural, not just a convention.

Institutional knowledge as the training signal. The skills framework is also how the firm’s quant knowledge is preserved and transmitted. When a senior researcher’s workflow is encoded as an approved skill, it stops being tacit knowledge stored only in their head. It becomes inspectable, testable, and transferable — surviving people moving on or moving up.

From 0 to 100+ skills

The first skills were built manually, in close collaboration between the AI team and senior researchers. The team deliberately built the first skills to be exemplary — well-named, well-typed, well-documented — because those first skills would become the training examples Claude would pattern-match against when proposing new ones.

This seeding strategy matters: the quality of your initial skills determines the quality of all subsequently proposed skills. Garbage in, garbage out applies to skill libraries too.

6. The transferable pattern: any signal→action domain

Man Group’s story is about finance, but the architecture is domain-agnostic. The signal→action pattern appears everywhere:

In each case, the architecture is the same:

1. Governed data access — the agent reads only what it’s permitted to read, via a typed API
2. Skills framework — domain knowledge encoded as versioned, approvable capabilities
3. Autonomous pipeline — the agent runs fetch → analyze → propose without per-step human approval
4. Human checkpoints — at skill approval and at the proposal gate, not in the middle of the loop
5. Structural boundary — the agent proposes; existing, audited systems act

The only thing that changes across domains is the vocabulary of the skills and the specific data types in the core layer. The governance model, the autonomy ladder, and the separation of research from execution are universal.

# core_data.py — the ONLY way the agent touches your data

def get_daily_metrics(
    entity_id: str,
    start_date: str,   # ISO 8601
    end_date: str,
    metrics: list[str]
) -> dict:
    """
    Returns {date: {metric: value}} for the requested entity and period.
    Raises PermissionError if the caller lacks access to entity_id.
    Logs all calls to the audit trail automatically.
    """
    _log_access(entity_id, metrics, start_date, end_date)
    _check_permissions(entity_id)
    return _fetch_from_store(entity_id, start_date, end_date, metrics)

# skills/analyze_trend.py

def analyze_trend(entity_id: str, metric: str, lookback_days: int = 90) -> dict:
    """
    Skill v1 · status: draft
    Analyzes recent trend for a single metric.
    Returns: {trend_direction, magnitude, confidence, narrative}
    Domain rule: minimum 30 days of data required for confidence > 0.5
    """
    data = get_daily_metrics(entity_id, _days_ago(lookback_days), _today(), [metric])
    if len(data) < 30:
        return {"confidence": 0.0, "narrative": "Insufficient data"}
    # ... statistical analysis ...
    return result

import anthropic

client = anthropic.Anthropic()

SKILLS_AS_TOOLS = [
    {
        "name": "analyze_trend",
        "description": "Analyze metric trend over time. Use when you need to understand direction and magnitude of change.",
        "input_schema": {
            "type": "object",
            "properties": {
                "entity_id": {"type": "string"},
                "metric": {"type": "string"},
                "lookback_days": {"type": "integer", "default": 90}
            },
            "required": ["entity_id", "metric"]
        }
    }
    # ... add more skills as you build them
]

def run_signal_pipeline(entity_id: str, research_question: str) -> str:
    """Run the autonomous research loop for a given entity and question."""
    messages = [
        {
            "role": "user",
            "content": f"Research entity {entity_id}. Question: {research_question}. "
                       f"Use the available skills to gather data, analyze it, and produce "
                       f"a structured proposal. Do not ask for confirmation between steps."
        }
    ]

    while True:
        response = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=4096,
            tools=SKILLS_AS_TOOLS,
            messages=messages
        )

        if response.stop_reason == "end_turn":
            return response.content[-1].text

        # Handle tool calls
        tool_uses = [b for b in response.content if b.type == "tool_use"]
        tool_results = []
        for tool_use in tool_uses:
            result = _dispatch_skill(tool_use.name, tool_use.input)
            tool_results.append({
                "type": "tool_result",
                "tool_use_id": tool_use.id,
                "content": str(result)
            })

        messages.append({"role": "assistant", "content": response.content})
        messages.append({"role": "user", "content": tool_results})

SKILL_REGISTRY = {
    "analyze_trend": {"version": "1.0", "status": "approved"},
    "propose_action": {"version": "0.1", "status": "draft"},
}

def _dispatch_skill(name: str, inputs: dict, allow_draft: bool = False):
    entry = SKILL_REGISTRY.get(name)
    if not entry:
        raise ValueError(f"Unknown skill: {name}")
    if entry["status"] == "draft" and not allow_draft:
        raise PermissionError(f"Skill '{name}' is in draft status — not approved for production")
    return SKILL_DISPATCH[name](**inputs)

def submit_for_review(proposal: str, entity_id: str, proposing_skill: str):
    """
    All agent proposals go here. Nothing downstream runs until a human approves.
    """
    review_id = _store_proposal(proposal, entity_id, proposing_skill)
    _notify_reviewer(review_id)
    print(f"Proposal submitted for review: {review_id}")
    print("No action will be taken until a human approves.")
    return review_id

Where to go next

• Watch the full talk by Tushara Fernando from Man Group at Code with Claude to see the live demos and the specific compliance conversation.
• Apply the same governance model to software agents with Trustworthy Agentic Workflows.
• For the tool use mechanics that power the skills dispatch layer, see Tool, Skill, or Subagent?.
• For memory patterns that let agents accumulate institutional knowledge over time, see Agents That Remember.