Tool vs Talent in Solon AI: When a Function Is Not Enough

Most agent tutorials stop at tools: give the model a function schema, hope it calls the right one. That works for get_time and hash_string. It falls apart when the model skips a knowledge search and opens a ticket, or when eighty APIs all land in one context window.

Solon AI keeps tools as the execution unit, then adds Talent as the product unit: tools plus SOP plus activation rules. Think of it this way:

• Tool ≈ a function
• Talent ≈ a class that owns those functions, their playbook, and when they appear

This post is a practical map of when to stay on tools, when to wrap them in a talent, and how registration actually works in Solon v4.0.3.

The product failure behind “just add more tools”

Bare tools only answer two questions for the model:

1. what can I call?
2. what args does it need?

They do not answer:

• should this capability even be visible right now?
• what order must I follow before a dangerous call?
• which tools belong to the same business domain?

That gap shows up as:

• premature side effects (ticket created before diagnosis)
• context blow-up (full tool tables on every turn)
• weak SOP compliance (model freestyles across domains)

Talent is Solon’s answer: a reusable package of awareness + instruction + tools, with automatic coloring so tools keep their domain identity.

Tool vs Talent in one table

From the official comparison:

Dimension Tool (FunctionTool) Talent (Talent) Unit Single function / method Instruction + tool set + state Abstraction Physical: how Logical: when and under which SOP Context awareness Passive isSupported(Prompt) can activate or hide Injected content Tool schema (JSON) System prompt fragment + tool list Constraint strength Weak — model freestyles from description Strong — SOP via getInstruction Registration defaultToolAdd / toolAdd defaultTalentAdd / talentAdd

They are not rivals. A talent contains tools. Registering a talent also registers its tools; you do not need a second defaultToolAdd for the same set.

Lifecycle: what actually runs at request time

When a request starts, Solon walks registered talents:

1. Gate — isSupported(prompt) filters inactive ones
2. Attach — onAttach(prompt) for warm-up / audit / context prep
3. Inject + color — getInstruction is merged into the system message; tools get talent metadata (coloring)
4. Reason + act — the model sees only active tools, with domain tags and SOP text

That is why talents can cut tokens: inactive domains never enter the tool table.

Pattern A: stay on Tool

Use a plain tool when the capability is:

• deterministic
• low risk
• self-describing from its schema
• not tied to a multi-step business policy

public class ClockTools extends AbsToolProvider {
    @ToolMapping(description = "Return the current server time in ISO-8601")
    public String now() {
        return Instant.now().toString();
    }
}

ChatModel chatModel = ChatModel.of(apiUrl)
        .apiKey(apiKey)
        .defaultModel(model)
        .defaultToolAdd(new ClockTools())
        .build();

Enter fullscreen mode Exit fullscreen mode

Also fine for request-scoped options when the branching is tiny:

chatModel.prompt("Weather in Hangzhou?")
        .options(o -> {
            o.systemPrompt("You are a weather assistant.");
            if ("admin".equals(role)) {
                o.toolAdd(new UserTool());
                o.toolAdd(new AdminTool());
            } else {
                o.toolAdd(new UserTool());
            }
        })
        .call();

Enter fullscreen mode Exit fullscreen mode

Good for spikes. Painful when the same role rules repeat across controllers.

Pattern B: upgrade to Talent

Wrap tools in a talent when you need any of:

• multi-step SOP before a side effect
• intent-based activation
• role / tenant aware tool surfaces
• reusable domain modules across ChatModel / ReActAgent / TeamAgent

Declarative build: TalentDesc

TalentDesc orderTalent = new TalentDesc("order_expert")
        .description("Order assistant")
        .isSupported(prompt -> prompt.getUserContent().contains("order"))
        .instruction(prompt -> {
            if ("VIP".equals(prompt.attr("user_level"))) {
                return "VIP customer: prefer fast_track_tool when eligible.";
            }
            return "Follow the standard order lookup flow.";
        })
        .toolAdd(new OrderTools());

Enter fullscreen mode Exit fullscreen mode

Fast for local, lambda-friendly definitions.

Engineered build: AbsTalent + @ToolMapping

public class TechSupportTalent extends AbsTalent {
    @Override
    public String name() {
        return "tech_support";
    }

    @Override
    public String description() {
        return "Technical support: diagnose before opening tickets";
    }

    @Override
    public boolean isSupported(Prompt prompt) {
        String content = prompt.getUserContent();
        return content != null && (
                content.contains("error")
                        || content.contains("故障")
                        || content.contains("报错"));
    }

    @Override
    public String getInstruction(Prompt prompt) {
        return """
                You are a tech support specialist. Follow this SOP:
                1. Search the knowledge base first (search_kb).
                2. Confirm the runtime version before any fix.
                3. Only open a ticket after diagnosis fails.
                """;
    }

    @ToolMapping(name = "search_kb", description = "Search the tech knowledge base")
    public String searchKb(@Param("query") String query) {
        return kbService.search(query);
    }

    @ToolMapping(name = "open_ticket", description = "Open a support ticket after diagnosis")
    public String openTicket(@Param("summary") String summary) {
        return ticketService.create(summary);
    }
}

Enter fullscreen mode Exit fullscreen mode

AbsTalent scans @ToolMapping methods via MethodToolProvider, same family of tool registration you already use for agents.

Role-aware tool surface inside one talent

public class AuthControlTalent extends AbsTalent {
    private final UserTool userTool = new UserTool();
    private final AdminTool adminTool = new AdminTool();

    @Override
    public String getInstruction(Prompt prompt) {
        return "You are a weather assistant. Respect the caller's role.";
    }

    @Override
    public boolean isSupported(Prompt prompt) {
        return prompt.getUserContent() != null
                && prompt.getUserContent().contains("weather");
    }

    @Override
    public Collection<FunctionTool> getTools(Prompt prompt) {
        String role = prompt.attrAs("role");
        if ("admin".equals(role)) {
            return Arrays.asList(userTool, adminTool);
        }
        return Collections.singletonList(userTool);
    }
}

Enter fullscreen mode Exit fullscreen mode

Call site stays thin:

ChatModel chatModel = ChatModel.of(apiUrl)
        .apiKey(apiKey)
        .defaultModel(model)
        .defaultTalentAdd(new AuthControlTalent())
        .build();

chatModel.prompt(Prompt.of("Weather in Hangzhou today?")
                .attrPut("role", role))
        .call();

Enter fullscreen mode Exit fullscreen mode

Or per request:

chatModel.prompt(Prompt.of("...").attrPut("role", role))
        .options(o -> o.talentAdd(new AuthControlTalent()))
        .call();

Enter fullscreen mode Exit fullscreen mode

Registration and priority

Scope API Every request on a model ChatModel.of(...).defaultTalentAdd(talent) One request prompt(...).options(o -> o.talentAdd(talent)) Ordered injection defaultTalentAdd(index, talent) / talentAdd(index, talent)

Multiple talents inject instructions in registration order. Their tools are colored with talent metadata so the model can align SOP text with the right tool group.

Same pattern works on ChatModel, SimpleAgent, ReActAgent, and TeamAgent.

Decision checklist

Signal Prefer Single pure function, no policy Tool Same branching copy-pasted at call sites Talent Must force order: search → confirm → mutate Talent (getInstruction) Hide whole domains by intent / tenant Talent (isSupported + dynamic getTools) Huge OpenAPI / MCP surface Gateway Talent (staged discovery) — still a talent, not a flat tool dump Prototype only Tool first; promote when the model mis-orders or over-calls

Official guidance in one line: start with tools; wrap in a talent when the model needs a playbook or a gate.

What this is not

• Talent is not a Claude Code Skill clone. Solon talents are developer-time capabilities (wired at build/request). Claude Skills lean runtime-learned. Solon documents the distinction explicitly.
• Talent is not a model-native standard. It is a framework pattern on top of prompt + tool-call.

Where to go next

• Tool vs Talent choice: solon.noear.org/article/1335
• Talent concept & interface: article/1331
• Two build styles: article/1332
• Registration & priority: article/1334
• Options tools vs talent encapsulation: article/1385
• Gateway talents for large surfaces: article/1353

If your agent keeps “knowing the tools” but still fails the business path, you usually do not need more tools. You need a talent that owns the path.