Summary
AI teams often use the word “agent” loosely. Breaking an agent down into skills (internalized reasoning) and tools (external services) changes how you observe what it does, upgrade its capabilities, govern its judgment, and deploy it across contexts. The distinction defines the technology approach.
The word “agent” gets used loosely. In asset management, it’s easy to call things like pulling data or parsing a notice “agentic.” Unless you narrow down your definition and understand the component parts of an agent, you struggle to upgrade them or govern the environment you’ve built.
Tech leaders are still coming to terms with the shift from generative to agentic thinking. Six months ago, the standard model for agentic AI in operations was a collection of small, single-purpose agents coordinated by an orchestration layer. For example, you might think of code that pulled data, investigated a trade break, and recommended a resolution. Each of these would be a discrete agent with an orchestration layer stitching them together.
The idea still holds, but how practitioners talk about agent structure has already shifted. Development teams are learning in practice that what looked like a multi-agent workflow is better factored as a single agent with multiple skills that the agent knows how to use. Pulling data is a skill the agent carries. Treat it as a standalone agent and you lose the ability to isolate what needs improving. If you decompose at the wrong layer, the internals of each “agent” are opaque. You can’t isolate what’s failing, so you end up rebuilding rather than upgrading.
A better model for an agent is to think of it as an outcome that delivers a complete result, powered by skills and tools underneath. Orchestration still applies when multiple agents power a workflow, but the definition of what constitutes a single agent has become much more granular. Defining the agent as an outcome forces you to identify the skills and tools before you build, rather than discovering the gaps after the agent is already running in production.
A useful analogy comes from the restaurant world. Think of an executive chef who plans the menu and calls orders to the kitchen. The sous chef is the agent. The culinary techniques they’ve internalized through training — how to balance a sauce, when to rest a protein, how to recover a dish that’s gone wrong — are the skills. The equipment they reach for, such as an immersion circulator, mandoline, or thermometer, are the tools. Swap out the thermometer for a better one and the chef’s judgment doesn’t change. The techniques stay; the equipment gets upgraded.
Skills encode domain knowledge and workflow logic by capturing things like sequencing rules, schema interpretation patterns, error-recovery strategies, and quality thresholds. The agent reads these capabilities and applies them at runtime to make decisions, using the skill to determine what to consider, how to sequence, when to retry, and when to escalate. Skills are defined separately from the agent, so they can be active and available without depending on an external call to function.
The job of tools is to execute. Tools are external services the agent invokes via a function call or API, such as an SQL engine for queries, a schema mapper for data transformations, a metadata catalog for indexing available datasets and field definitions, or a quality checker for validation. The agent gives each tool precise instructions and receives a result. Because tools are modular, the agent’s reasoning stays stable when you replace an SQL engine or upgrade a schema mapper.
How you divide skills from tools determines what you can upgrade independently and what you have to rebuild together. Skills demand workflow expertise to encode logic and writing them well requires a deep understanding of the outcome you want an agent to deliver. Building tools requires integration expertise between different endpoints.
You want to build something reusable that will handle multiple vendors and future scenarios. A hypothetical data engineering agent building new connectors that pull data from vendors into your data lake is a good example.
The resulting agent would assess the task. It would decide that schema mapping should precede validation while it can generate documentation later, in parallel with testing. Schema reasoning then surfaces the interpretive judgments the agent carries to understand what it’s looking at. It recognizes that different vendors represent a trade date differently and resolves the ambiguity before passing data downstream. The sequencing logic, interpretive judgment, and error-recovery strategies are skills the agent carries and applies at runtime.
To act on those judgments, the agent coordinates tools. It provides a source schema to the mapper, queries the metadata catalog to see what already exists, calls the code generator for boilerplate, and runs the data quality rules for validation. After each step, it assesses whether the output matches the defined outcome and is production ready.
Every new connector follows the same pattern: the agent applies pipeline planning and schema reasoning to design the approach, then calls the code generator, metadata catalog, schema mapper, and quality checker in sequence, with error recovery governing what happens when any tool call returns an unexpected result. The agent can then work with other vendor data, using the same skills, even though vendor-specific tool parameters change each time.
The old model of loose parts wired together without clear decomposition is hard to upgrade, govern, and deploy. The boundaries are invisible, so every change risks breaking something you can’t see.
A clean separation means you can trace what went wrong. Tool calls produce logs that you can audit, replay, and trace failures. Skills produce decisions, and those decisions are visible only in the agent’s behavior. Testing whether the agent’s reasoning holds up under varied conditions requires eval frameworks and careful prompt design, because you can’t audit a judgment call the way you audit an API response.
It also creates clarity around what to upgrade and how. Improving how the agent reasons means working at the workflow layer with a refined understanding of the operational process and sharper logic. Improving what the agent can reach means working at the integration layer. Pointing it at a faster API endpoint might take a day, while migrating from one data infrastructure to another is a strategic decision with a multi-year timeline. Without a separation of concerns, it's harder to determine what needs to be changed.
Operational control and governance clarity increase as well. You can set rate limits and permissions on tools. You can evaluate whether the agent’s skill-generated judgment holds up across varied conditions and edge cases, within what you’ve decided to be acceptable limits. That’s a different kind of oversight than checking a configuration.
“Agentic AI creates a governance dilemma unlike any previous technology’s. Tools are owned and predictable, whereas people are autonomous and must be supervised. Agentic systems fall somewhere in between: They are owned like assets, but they act in ways that require oversight, akin to employees. The question for managers is no longer ‘How do we set guardrails for tools?’ but ‘How do we assign decision rights, accountability, and oversight to actors we own but don’t fully control?’”i
Finally, it gives you a better handle on your deployment logic. In one setting, skills get assembled into agent configurations in a sandbox that allows users to combine skills to build their own agent or modify an existing one. In another, the same skills get exposed as Model Context Protocol (MCP) tools to provide access to other data and interfaces. Keeping skills and tools discrete lets you reconfigure how they’re assembled and delivered without rebuilding agents from scratch.
We build to this decomposition because loose parts you can’t observe, upgrade, or govern cleanly aren’t a foundation you can scale on. You first have to look at an agent as a deliberate composition of skills and tools, before you can make informed decisions about deployment and managing risk. Otherwise, you’re launching and scaling something you haven’t defined.
Vera Shulgina
Vera is responsible for Arcesium's data strategy with a focus on driving value for clients through data solutions and data partner integrations.
Sources:
[i] MIT Sloan Management Review, 2025. https://sloanreview.mit.edu/projects/the-emerging-agentic-enterprise-how-leaders-must-navigate-a-new-age-of-ai/
No spam. Just the latest releases and tips, interesting articles, and exclusive interviews in your inbox every week.
