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();

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();

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());

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);
    }
}

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);
    }
}

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();

Or per request:

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

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.