Ambarish Majumdar is a Marketing Science Partner at Meta, where he uses his SME knowledge in Marketing Science to better AI models.
AI agents are getting a lot of attention, but teams often start at the wrong level. Before building an agent, it helps to think about the individual skills the agent actually needs.
A skill does one thing well. It might retrieve information, summarize a document, classify a request or validate an output. An agent operates at a different level. It decides which capabilities to use, in what order and what to do with the results. Well-designed skills can therefore be combined to create agentic behavior without building one large, complicated agent.
Anthropic makes a similar distinction in its work on building effective agents, separating workflows, where models and tools follow predefined paths, from agents, where the model dynamically determines how to accomplish a task.
You don’t necessarily need to start by programming an agent. Instead, start by programming the capabilities that the agent will need. At Microsoft, I worked on Bing Ads relevance measurement, using experimentation and analytics to break broad problems like ad relevance and quality into components that could be measured and improved independently.
I see the same principle applying to AI today: Build focused capabilities that can be tested on their own, then orchestrate them into an agent that can put those capabilities to work together.
Build skills that work together.
A useful skill should have a clear job, defined inputs and a predictable output. Its output should also be usable by another skill.
Consider customer support. One skill might identify the customer’s problem, another retrieve account information, a third propose a resolution and another validate it against company policy. None needs to be an agent. An orchestration layer can connect them and pass relevant outputs between skills. The same skills can then be reused across different workflows.
Think about a skill almost like an API: What does it need? What does it return? What happens when it fails? Can another component reliably use its output?
This also makes evaluation easier. Retrieval can be measured on whether it finds the right information, classification against known examples and validation on whether it catches specific errors. When everything sits inside one large prompt, identifying what failed becomes much harder.
Orchestration is what makes the system agentic.
An orchestrator executing five skills in a predetermined sequence is essentially running a workflow, but suppose it examines an intermediate result and decides what happens next. It might call another skill, retry a step, ask the user for more information or invoke additional validation. The system is now behaving more like an agent.
Anthropic describes a related “orchestrator-workers” pattern, where a central model dynamically breaks a problem into subtasks, delegates them and combines the results. The same principle can work with skills. A relatively small library of reusable capabilities can support many workflows depending on how they are orchestrated.
This also gives teams control over autonomy. Predictable parts of a process can remain deterministic, while the model makes decisions where judgment adds value. The entire system doesn’t need to be autonomous to benefit from agentic behavior.
Context windows change skill design.
Modern models support increasingly large context windows, making it tempting to pass everything forward: conversation history, documents, instructions and outputs from previous steps. But just because information fits into the context window doesn’t mean every skill needs it.
Anthropic makes this point in its work on context engineering, describing context as a finite resource that needs to be actively curated. OpenAI reaches a similar conclusion in its write-up on its internal data agent, describing context as central to agent performance while noting that providing less, more relevant context can produce better results.
Imagine a workflow that is six steps deep. The next skill may need the user’s original request and the previous step’s output. It probably doesn’t need every document and intermediate response generated along the way.
Unnecessary context consumes tokens, can increase latency and gives the model more information to sort through. Instead, treat context as part of a skill’s interface. When designing a skill, define not only its inputs and outputs but also the context it needs.
The orchestrator can maintain broader workflow state while passing relevant information to each skill. Earlier results can be stored as structured state or concise summaries instead of repeatedly carrying the entire history.
Separate instructions, state and knowledge.
It is also useful to separate three things that often get bundled into one large prompt. Instructions define what the skill should do. State captures what has happened in the current workflow. Knowledge provides external information needed to complete the task.
Keeping these separate makes systems easier to maintain and debug. Business knowledge can change without redesigning a skill, individual skills can be evaluated independently and orchestration problems can be investigated without rewriting every underlying capability. These boundaries become increasingly valuable as the system grows.
Start with skills and then add agency.
Instead of asking, “How do we build an agent for this process?” start with a simpler question: “What capabilities does this process actually require?”
Build those capabilities as focused skills. Define their inputs and outputs. Decide what context each needs. Test them independently, and then connect them.
Some problems only require a fixed workflow. Others benefit from letting the model decide which skill should execute next. A smaller number may justify substantially more autonomy. The architecture can evolve with the problem instead of starting with maximum agency.
The goal shouldn’t be to build as many agents as possible. It should be to build reliable AI capabilities that can be composed into more sophisticated systems when the problem requires it.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?