The Next Generation of AI Agents Will Not Just Answer Questions. They Will Do the Work.

Ask an AI to write a follow-up email to a customer and it will write a good one, often better than what you would have written on a Thursday evening.

Now watch what happens next.

You copy the text. You open your email client. You find the customer and check that the address belongs to the right person, not to the other Sarah at the same company. You send it. You update the CRM, or you mean to. Then you set a reminder to follow up again in a week, because nothing else will.

The AI solved the writing problem. It did not touch the workflow.

For three years the interesting question was what a model could generate. The question now is what an agent can actually finish. The usual shorthand is assistant to agent, and the shorthand is fine. The details are where it gets interesting, because "agent" is one of the most overused words in software.

1. What is an AI agent?

An AI agent can interpret a goal, determine the actions required, use tools or external systems, execute tasks, evaluate results, and continue a workflow with an appropriate level of autonomy.

That is a working definition rather than a standard one. Terminology differs across vendors and research communities, and no standards body has settled what counts. It is still useful, because it names the parts that must exist:

• Goal. An outcome stated by a person, not a single instruction.
• Reasoning. Deciding what would have to be true for the goal to be met.
• Context. The information needed to decide, retrieved rather than assumed.
• Tools. The external systems the agent is allowed to touch.
• Actions. The ability to change something outside the conversation.
• State. A record of what has already happened, so work can resume.
• Workflow. A sequence with a defined end, not an open-ended chat.
• Feedback. Reading the result of an action and reacting to it.
• Autonomy. How much the agent does before it stops and asks.

2. AI assistant vs AI agent

An AI assistant primarily responds to human requests by generating information, content, recommendations, or other outputs.

Two clarifications. This is not a claim that every agent is fully autonomous; autonomy sits on a spectrum, and most useful systems stop well short of the end of it. The engineering question is where exactly the handoff to a person sits. And capability is not quality: an assistant that answers a hard question correctly is worth more than an agent that confidently does the wrong thing six times.

3. The real difference is execution

Traditional AI: "Here is how you can send a follow-up. Start with a subject line that references their last question, keep the body under 120 words, and mention the pricing page. Here is a draft."

Agentic AI: "I checked the account history, found the thread where the price objection came up, prepared a follow-up that answers it, and sent it under the rule you configured for this segment. The step is logged and the next touch is scheduled."

The second response is not a better paragraph. It describes actions taken rather than instructions that could be followed. That is what puts an agent between intent and action: intent is what a person has, action is what changes the business, and in between sits everything that used to be human labour.

4. Why tools change everything

A language model on its own produces outputs. That is useful and it is also a hard ceiling, because almost nothing in a business happens inside a text response. Tools break the ceiling. A tool is a defined operation the model can call: search, email, calendar, CRM, database, browser, documents, payment systems, analytics, internal APIs.

The composition is worth writing out, because the middle step usually gets skipped:

• AI model + tools = actionable AI. The system can affect things outside itself, but it is still answering requests one at a time.
• AI model + tools + workflow + permissions = AI agent. The workflow gives it a sequence with an end. Permissions define what it may do without asking.

5. From tools to MCP

Tools solve the capability problem one integration at a time, which does not scale: every model needs a connection to every system, and every system needs an implementation for every model. The Model Context Protocol collapses that fan-out into a single interface, and the last few years of AI sales tooling show why that matters commercially.

MCP is an open protocol that standardises how AI applications reach external tools, data sources, and services. It uses JSON-RPC 2.0 and defines three kinds of server-side feature: tools, which are callable operations; resources, which supply context; and prompts, which supply reusable message templates. A tools-only server is normal.

The specification has moved quickly. The current revision is 2026-07-28, which made the protocol stateless: the initialize handshake is gone along with the session header, and each request now carries the protocol version and capabilities it needs. It also added Multi Round-Trip Requests, letting a server ask for a confirmation without holding a connection open. Earlier revisions remain in use, and compatibility across them is a deliberate implementation choice.

Two things MCP is not. It is not an agent: it is a protocol, with no opinions about goals or workflows. And it is not a guarantee of compatibility. An HTTP endpoint speaking JSON-RPC is not proof that two systems share a revision and support what a workflow needs.

For sales tooling the implication is straightforward. A platform that exposes its capabilities through MCP stops needing a custom integration per agent per vendor. SalesRuns already connects outward to external systems. Exposing SalesRuns itself as an MCP server is a larger step, and not something to describe in the present tense until it exists.

6. AI agents need more than tools

Tools answer one question: what can this agent do? Not the harder one, which decides whether it is usable: how should this organisation do it?

An email tool sends email. It does not know who should receive it, when it is appropriate to send, what approval a message needs, what makes a follow-up good rather than merely grammatical, or when the correct decision is to send nothing. Those are not capabilities. They are judgments, and they belong to the business rather than to the model.

Which is why the composition that produces something useful has more terms in it:

• Model supplies reasoning and language.
• Context supplies the specific situation the work happens in.
• Tools supply the ability to act on external systems.
• Skills supply the method, meaning how this kind of work is supposed to be done here.
• Policies supply the limits: what is allowed, what needs approval, what is never acceptable.

Tools tell an agent what it can do. Skills tell it how the work is done. That is the difference between a system that can technically complete a task and one a company would let run unsupervised.

7. What are AI agent skills?

An AI Agent Skill is a reusable set of instructions, resources, and workflow knowledge that teaches an agent how to perform a specific type of work.

Skills are already past the concept stage. Anthropic's Agent Skills are filesystem-based: a directory containing a SKILL.md file with metadata, plus optional reference material and scripts. They load progressively, so the agent sees only a name and description until a skill becomes relevant, then the instructions, then supporting files when needed. Pre-built skills cover document work such as PDF, Word, Excel, and PowerPoint. The format was published as an open standard.

OpenAI's Agents SDK lists progressive disclosure via skills as a standard primitive, alongside tool use through MCP, instructions in AGENTS.md, shell execution, and file editing. Its coding agent goes further: Codex runs tasks in isolated cloud environments and returns a reviewable diff and pull request, and on macOS it can turn a recording of a workflow into a reusable capability. The knowledge was never written down, and it did not have to be.

Skills in sales could cover prospect research, qualification, outreach preparation, meeting preparation, response handling, pipeline hygiene, and reporting. Each is a method rather than a capability, and each currently lives in a rep's head or a slide deck nobody has updated. It deserves its own treatment, and it will get one.

8. Why sales is a natural domain for AI agents

Sales work fits agentic systems for a structural rather than fashionable reason. It is full of workflows that are repetitive in shape and variable in content, which is the combination that defeats both traditional automation and pure prompting.

• Prospect research and contact organisation.
• Qualification against criteria that need judgment rather than a filter.
• Outreach preparation and sequencing.
• Follow-up, repetitive in timing and entirely dependent on context in content.
• Response handling, including the awkward middle cases that are neither a yes nor a no.
• Meeting preparation, which means assembling what is already known.
• CRM updates, which everyone agrees matter and almost nobody does consistently.
• Reporting, which is a summarisation problem wrapped in a data problem.

Each follows a shape that has been stable in sales for decades. Deterministic automation handles the trigger and the action. It has never handled the middle.

Sales is not the only industry with this shape. Support, finance operations, recruiting, and legal review contain similar workflows. The claim here is narrower: sales fits the pattern well, and the tooling sales teams already run is unusually well instrumented.

9. From AI assistant to AI sales agent

The difference is easier to see in a concrete request than in a definition.

With an assistant the request is narrow and the work is yours. "Write a sales email to this prospect" produces an email. Everything after that is manual, which is to say everything that involves touching a system.

With an agent the request is a goal and the workflow is the agent's problem. "Find qualified prospects in this market and start the approved outreach workflow" produces a different structure:

• Find candidate companies and contacts that match the stated market.
• Apply qualification criteria, and explain what disqualified the ones that failed.
• Organise the resulting set so it can be reviewed.
• Prepare messaging appropriate to each segment rather than one template for all.
• Apply the sending rules already configured: volume limits, timing windows, exclusions.
• Request approval where policy requires it, and wait.
• Execute the approved outreach.
• Record what was done so the CRM reflects reality rather than intent.
• Continue as replies arrive, and stop when the sequence ends.

The point is not that this removes the salesperson. It is that the person specifies the goal and the agent manages the workflow, and the two stop being interchangeable. The failure modes matter too: an agent that finds unqualified prospects at volume is worse than no agent, and one that ignores configured limits is a deliverability incident. The rules matter as much as the model.

10. SalesRuns as a sales execution layer

Everything above points at a division of labour. General models provide reasoning. Skills provide method. MCP provides connectivity. None of the three sends an email, holds a contact list, tracks campaign state, enforces a sending limit, or keeps an audit trail.

That is the layer SalesRuns occupies. Not an email sender, not a CRM, not an outreach tool, not a chatbot: an execution layer for AI agents that need to perform real sales work. It is the part that owns the consequences.

Stating that plainly: SalesRuns today performs sales work across email, WhatsApp, Telegram, LINE, Slack, Discord, and WeCom, with a workflow engine handling sequencing, retries, and branching. A SalesRuns MCP server, which would let external agents call those capabilities directly, is the forward-looking part of this diagram rather than a current feature. Being precise about that is not modesty. An architecture claim that turns out to be marketing damages the credibility of the parts that are real.

11. The emerging AI agent stack

Zoom out and a stack has formed. Naming the layers is worth doing, because most confusion about agents comes from conflating two of them.

Layer 1 gets the attention and improves faster than anything else. It does not dissolve the layers underneath it. A more capable model does not arrive with email infrastructure, a maintained contact database, permission systems, campaign state, sending controls, or the rules a business operates under. It arrives with a better ability to reason about all of those things, which is a real contribution and not a substitute.

12. Why general AI agents still need specialized business systems

A general-purpose agent can be extremely capable. Given a sandbox, a shell, files, and network access, it can write code, run commands, read a repository, and hand back a reviewed result.

What it should not have to do is reinvent operational machinery that already exists. Email delivery with reputation management is not a weekend project. Neither is a contact database that stays accurate, or a permission model that survives an audit.

So the likely future is not one AI replacing every SaaS application. It is general agents orchestrating specialized capabilities that already do their jobs well.

• General intelligence decides what should happen and in what order.
• Specialized infrastructure knows how to make it happen safely, reliably, and in a way that can be explained afterwards.
• Practical business automation is what you get when both are present and neither pretends to do the other's job.

There is an unglamorous version closer to the truth. The bottleneck in most sales operations was never intelligence. It was follow-through, and follow-through is an infrastructure problem.

13. What this means for sales software

A framework for three decades of sales tooling, offered as this article's reading rather than an established taxonomy. Generations overlap, and many companies run all five at once.

The move from 3 to 4 is the one most teams are living through, and it is mostly a change in what software is permitted to touch. An assistant writes into a chat window. An agent writes into a system, which is why permissions stop being an afterthought and start being part of the product.

The move from 4 to 5 is less obvious and possibly more consequential. In generation 4, a sales AI agent is a product somebody buys. In generation 5, it is a capability many agents from many vendors can call, which changes who the customer is.

14. SalesRuns: from SaaS application to agent-accessible sales infrastructure

For most of software history there has been one path between a person and a system's capabilities: a person opens an interface, uses it, and the work happens. Agents introduce a second. A person states a goal, the agent reaches the capability, and the work happens without anyone touching the interface.

That produces a different question for a platform. Not "is our interface better than the competition's" but "can an agent we have never met use this capability correctly, safely, and in a way that can be audited afterwards." Answering it needs stable interfaces, explicit permissions, idempotent operations, and state that survives being interrupted.

Which is a reasonable description of what SalesRuns is being built toward. General models keep improving and that is good news for everyone. What does not improve on its own is the operational layer underneath: the contact records, the sending limits, the campaign state, the audit trail, the rules that say what this business will and will not do. An AI Sales Agent does not need to be the smartest component in that stack. SalesRuns intends to be the most reliable place for sales work to happen.

15. What should stay human?

Agentic AI described without limits is not a serious argument, so here is the limit. Real sales systems need permissions, approval policies, escalation paths, auditability, and rate controls. None of those are obstacles to agents doing useful work. They are what makes it possible to let an agent work.

The line that makes sense is drawn around consequence rather than difficulty. Agents can research, organise, draft, classify, prepare, and act inside limits someone configured. A person should still approve the things that are expensive to undo.

• Agents can prepare a proposal, assemble the account history, and flag the risks.
• A person should approve a major discount, because a discount is a pricing precedent and not a task.
• Agents can draft a contract summary and check it against internal terms.
• A person should approve the contract, and in many cases a second person should.
• Agents can identify that a customer is unusually sensitive and worth handling differently.
• A person should make any commitment the company has not made before.

This is a boundary rather than a limitation, because it is where the value sits. Delegating mechanical work is only useful if judgment stays sharp where it matters, and a system that blurs that line produces confident errors exactly where errors are most expensive.

16. The future is not "AI replaces SaaS"

The most common misreading of agentic AI is that agents consume software and leave nothing behind. It is tidy and it gets the mechanism wrong. What changes is how software is reached, not whether it exists.

Today the dominant path runs through an interface. Agents add a second that runs through tool calls, and in an MCP-shaped world that path is standardised rather than bespoke. The interface does not disappear either: plenty of work is faster by hand, and plenty is better when a person can see the state directly.

So the honest shape of the near future is three things coexisting rather than one replacing another: a human interface for work people want to do themselves, an agent interface for work they would rather delegate, and customer engagement infrastructure underneath that has to be correct in both cases.

For a platform like SalesRuns that is a better position than it sounds. A company that only built a good interface has to learn how to expose capabilities safely. One that only built plumbing has to learn what people need. The interesting products do both.