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: what can I call? 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: Gate — isSupported(prompt) filters inactive ones Attach — onAttach(prompt) for warm-up / audit / context prep Inject + color — getInstruction is merged into the system message; tools get talent metadata (coloring) 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 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.