Agentic AI for developers: from chat to agents

In Anthropic's June 2026 Economic Index report, the median chat or Cowork conversation that produces a blog post runs 13 rounds of back-and-forth. The median Claude Code session for the same job contains a single human prompt. That gap is agentic AI: a model that plans, calls tools and checks its own results in a loop until the work is done. By the end, you will have a read-only tool wired into an agent, with rules around it.

Agents are already past the demo stage. In LangChain's State of Agent Engineering survey of 1,340 practitioners, 57.3% said they have agents in production, up from 51% a year earlier. They are also where budgets go to die. Gartner predicts that more than 40% of agentic AI projects will be canceled by the end of 2027. It blames escalating costs and unclear business value. My bet is that the survivors will be the teams that scope their agents' tools tightly and measure what the agents do.

What is agentic AI, and how is it different from a chatbot?

A chatbot gives you an answer. You read it, decide what to do, run it yourself and paste the result back. An agent closes that loop on its own. It picks a tool, reads what the tool returns, and decides the next step without waiting for you.

Anthropic draws the line between two designs in its engineering guide, Building effective agents. Workflows are "systems where LLMs and tools are orchestrated through predefined code paths". Agents are the other kind:

“Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.”

— Anthropic, Building effective agents

That difference decides how you build and test one. In a workflow, your code fixes the order of the steps, so you can test each one. In an agent, the model chooses the order at run time. The same guide warns that "the autonomous nature of agents means higher costs, and the potential for compounding errors."

The table puts the three side by side.

Anthropic's own advice is to look for "the simplest solution possible, and only increasing complexity when needed." I agree with it. When you already know a task's steps, a fixed workflow you can test beats an agent you can't predict.

How far the move from chat to agents has gone

The clearest signal comes from usage, not surveys. Anthropic's June 2026 report says Claude sessions "now increasingly consist of long-running agentic tasks" as Claude Code and Cowork grow. It credits about two thirds of the autonomy gap between Claude Code and chat to delegation. People hand over the same tasks more, rather than different ones. People also pick heavier models for agent work: 54% of Claude Code sessions are served by Opus, against 10% of chat and Cowork conversations.

Here is what the surveys and forecasts add.

Read together, the two sources agree. Agents in production are now normal among teams that build them. Many projects that start will still not last. LangChain ran a public survey as an agent-framework company. So I read 57.3% as "common among builders", not "common everywhere".

Gartner's vendor count is the warning for buyers. It describes "agent washing": "the rebranding of products such as AI assistants and chatbots without significant agentic capabilities". My test is simple: a product that can't name the tools its agent calls is probably a chatbot with a new label.

MCP: the standard way agents reach your tools

An agent is only as useful as the tools it can call. The Model Context Protocol (MCP) gives every tool one interface. A server exposes tools, and any MCP client can discover and call them. If you followed our guide to connecting FilmCraft to Claude Code with MCP, you have already used one.

MCP is no longer one vendor's project. On 9 December 2025 the Linux Foundation announced the Agentic AI Foundation, with Anthropic's MCP, Block's goose and OpenAI's AGENTS.md as its founding contributions. The announcement counted "more than 10,000 published MCP servers".

What the 2026-07-28 MCP spec changed

The latest revision rebuilds the protocol's core. These are the changes a tool author meets first, from the official 2026-07-28 changelog:

• Sessions are gone. The Mcp-Session-Id header and the initialize handshake are removed. Each request carries its protocol version and client capabilities in _meta. Any server instance can answer any request.

• Servers must implement server/discover, which advertises their protocol versions, capabilities and identity.

• Tasks moved out of the core into the official extension io.modelcontextprotocol/tasks, and clients poll them with tasks/get.

• Multi Round-Trip Requests replace server-initiated sampling, elicitation and roots requests. A server that needs input returns resultType: "input_required". The client then retries with the answers.

• Roots, Sampling and Logging are deprecated, under a new policy with "a minimum twelve-month deprecation window".

For a remote server, statelessness means it can scale like any other HTTP service. Anything you used to keep in a session now travels as a handle the server mints and the client passes back as a tool argument. In my reading, a local stdio tool like the one below barely notices the change.

Build a read-only MCP tool for an agent

The safest first tool is one that can only read. The server below lets an agent read the last lines of your application's logs, the first thing you check when something breaks. It can't write, run commands, reach the network or open files outside one folder.

Step 1: Install the MCP Python SDK

The official SDK is the mcp package, and its README installs it with the cli extra:

python3 -m venv .venv
. .venv/bin/activate
pip install "mcp[cli]"

That installs version 2 of the SDK, which renamed FastMCP to MCPServer. Code from older tutorials that imports mcp.server.fastmcp stops with a ModuleNotFoundError; the error itself suggests pinning mcp<2 if you need to keep running v1 code.

Step 2: Write the folder check

Save this as the top of log_reader.py. It fixes the one folder the server may read and refuses every path that resolves outside it:

"""A read-only MCP server: an agent may read your app's recent log lines, and nothing else."""
import os
from collections import deque
from pathlib import Path

from mcp.server import MCPServer
from mcp.server.mcpserver.exceptions import ToolError
from mcp.types import ToolAnnotations

# The one folder this server reads. Nothing outside it, nothing that isn't a .log file.
LOG_DIR = Path(os.environ.get("LOG_DIR", "./logs")).resolve()
MAX_LINES = 200

mcp = MCPServer("log-reader")

def _allowed(path: Path) -> bool:
    real = path.resolve()  # follows symlinks and "..", so neither can leave LOG_DIR
    return real.parent == LOG_DIR and real.suffix == ".log" and real.is_file()

The check resolves symlinks and .. before it compares folders. A request for ../.env is refused, and so is a symlink that points elsewhere.

Step 3: Add the two read-only tools

Append the tools to the same file. One lists the log files, and the other returns the tail of one file:

# Hints for the client: these tools change nothing and reach nothing outside LOG_DIR.
READ_ONLY = ToolAnnotations(read_only_hint=True, open_world_hint=False)

@mcp.tool(annotations=READ_ONLY)
def list_logs() -> list[str]:
    """List the .log files the agent is allowed to read."""
    return sorted(p.name for p in LOG_DIR.glob("*.log") if _allowed(p))

@mcp.tool(annotations=READ_ONLY)
def tail_log(name: str, lines: int = 50) -> str:
    """Return the last `lines` lines (1 to 200) of one file from list_logs."""
    path = LOG_DIR / name
    if not _allowed(path):
        raise ToolError(f"{name!r} is not a .log file in {LOG_DIR}")
    lines = max(1, min(lines, MAX_LINES))
    with path.resolve().open(encoding="utf-8", errors="replace") as f:
        return "".join(deque(f, maxlen=lines))

if __name__ == "__main__":
    mcp.run(transport="stdio")

Raising ToolError sends your message back to the model as a failed call it can read, not a bare crash message.

The 200-line cap matters too. It stops one huge log from filling the model's context window.

The annotations are only hints. The SDK's own documentation for ToolAnnotations says clients should never make tool use decisions based on annotations received from untrusted servers. The folder check is the real boundary.

Step 4: Register the server with Claude Code

Claude Code's MCP documentation adds a local server with claude mcp add. Everything after -- is the command that starts it. Project scope writes the entry to .mcp.json, so everyone on the repository gets the same tool:

claude mcp add --env LOG_DIR=./logs --transport stdio --scope project log-reader -- .venv/bin/python log_reader.py

Keep --env before the server's name. It accepts several KEY=value pairs. In Claude Code 2.1.322, a name placed after it is read as one more variable, and the command stops with "Invalid environment variable format". The command then writes the file below, which you can commit:

{
  "mcpServers": {
    "log-reader": {
      "type": "stdio",
      "command": ".venv/bin/python",
      "args": [
        "log_reader.py"
      ],
      "env": {
        "LOG_DIR": "./logs"
      }
    }
  }
}

Claude Code asks for your approval before it uses a project-scoped server from .mcp.json. Until you give it, claude mcp list shows the server as pending approval. Inside a session, /mcp shows whether it connected.

Step 5: Pre-approve the reads and block risky commands

Claude Code's permission rules take the form Tool or Tool(specifier), and a tool from an MCP server is named mcp__<server>__<tool>. This .claude/settings.json lets the agent read logs without asking each time, while git push and your .env file stay off-limits:

{
  "permissions": {
    "allow": [
      "mcp__log-reader__list_logs",
      "mcp__log-reader__tail_log"
    ],
    "deny": [
      "Bash(git push *)",
      "Read(./.env)"
    ]
  }
}

Deny rules win, because Claude Code checks deny first, then ask, then allow. The documentation also stresses that these rules are enforced by Claude Code, not by the model. They have gaps, though. A deny rule on Bash(curl *) does not stop the same request made through sh -c. For anything that matters, put the limit inside the tool, as the folder check in Step 2 does.

Where agents go wrong: OWASP's list for agentic apps

In December 2025 the OWASP GenAI Security Project published its Top 10 for Agentic Applications. Its first entry names the root problem: agents and the underlying model "cannot reliably distinguish instructions from related content." Anything an agent reads can try to steer it.

The first five entries are the ones a developer meets first:

• ASI01 Agent Goal Hijack: manipulated prompts, deceptive tool outputs, malicious files or poisoned external data redirect what the agent is trying to do. We covered a real case: a file in a Downloads folder that tried to trick coding agents into installing malware.

• ASI02 Tool Misuse and Exploitation: the agent stays inside its permissions but uses a legitimate tool unsafely, "for example deleting valuable data, over-invoking costly APIs, or exfiltrating information."

• ASI03 Identity and Privilege Abuse: inherited credentials or trust between agents is used to escalate access; OWASP counts API keys, OAuth tokens and delegated user sessions as part of an agent's identity.

• ASI04 Agentic Supply Chain Vulnerabilities: a model, tool, plug-in or MCP server from a third party is malicious or tampered with; OWASP notes that tool definitions increasingly come via MCP servers.

• ASI05 Unexpected Code Execution (RCE): code the agent generates and runs on the spot, which can slip past traditional security controls.

The other five cover Memory & Context Poisoning, Insecure Inter-Agent Communication, Cascading Failures, Human-Agent Trust Exploitation and Rogue Agents. They describe what goes wrong once agents keep memory, talk to each other or earn your trust.

OWASP's answer to most of them is least agency. Each tool gets a profile of scopes, rate limits and egress allowlists, such as "read-only queries for databases, no send/delete rights for email summarizers". The log reader follows the same idea. It reads one folder, and the agent gets nothing else from it.

What agents still can't do reliably

Quality, not cost, is what holds agents back. LangChain's respondents named quality the biggest barrier to production, and latency the second at 20%. Cost was "less frequently cited as a concern than in previous years".

Evaluation is also behind adoption. In the same survey, 29.5% of respondents don't evaluate their agents at all, and 22.8% of those with agents in production don't either. Where teams do check, human review (59.8%) and LLM-as-judge (53.3%) lead.

Long runs magnify small mistakes. Say an agent misreads one log line in step two of a twenty-step fix. Every later step builds on that misreading, and the final diff still looks confident. It is the same reason coding agents need smaller tasks and more code review.

Finally, an agent needs a fence it can't talk its way through, which a prompt is not. Our report on the OpenAI test agents that escaped their sandbox and reached Hugging Face shows what happens when the boundary is shared infrastructure rather than a tool that can only do one thing.

Which agent jobs to hand over first

I'd hand over work in this order, moving on only when the last step has held for a while:

1. Reading and summarising: logs, failing tests and CI output, through read-only tools like the log reader.

2. Changes that land as a diff or a pull request a person reviews, never straight onto the main branch.

3. Anything that sends, deletes, pays or deploys stays behind an ask rule or a human approval, whatever the demo shows.

Whatever you hand over, record what the agent did. Of LangChain's respondents, 89% have some form of observability on their agents, and 94% of those with agents in production do. A trace is how you find the step where a run went wrong.

Start with the log reader. Give it a week of real incidents, read the traces, and only then decide whether your agent has earned a tool that can write.