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:

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

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

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:
  


• Two build styles:
  


• Options tools vs talent encapsulation:
  

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.