umma.dev

Agents

An agent is an LLM given a goal, a set of tools and the ability to decide what to do next, rather than just returning a single response. Instead of one prompt in, one answer out, an agent runs in a cycle: it reads the current state, picks an action (call a tool, ask a question, write a file), observes the result, and decides whether to continue or stop. The model isn’t just predicting text anymore, it’s making decisions about how to reach a goal.

What separates an agent from a chatbot is persistence and tool use. A chatbot answers a question. An agent can open a file, run a test, read the failure, fix the code and run the test again, all without a human re-prompting it at each step.

The Agentic Loop

The core mechanism behind most coding agents is a loop: gather context, take an action, check the result, repeat until the goal is met or a stopping condition is hit.

while not done:
    context = gather_context()
    action = model.decide(context)
    result = execute(action)
    done = check_goal(result)

This sounds simple but the details matter. A good loop needs a clear termination condition (otherwise the agent can spin forever burning tokens), a way to recover from failed actions, and some memory of what’s already been tried so it doesn’t repeat mistakes. Tools like Claude Code use this pattern for everything from fixing a failing test to running a scheduled task on an interval, where the loop pauses between iterations and picks back up with the previous context still intact.

Skills

Skills are packaged, reusable instructions an agent can load partway through a task instead of trying to hold every possible procedure in its default behaviour. Rather than cramming a system prompt with instructions for every situation, a skill is loaded on demand, when the task actually matches it.

This keeps the agent’s default context small and focused, while still letting it handle specialised workflows like a deploy checklist, a code review process, or a project-specific convention. It’s a similar idea to lazy loading in software, you don’t ship the whole library, you import the module you need when you need it.

Model Context Protocol (MCP)

Skills solve how an agent gets instructions on demand. MCP solves a related but different problem, how an agent connects to data and tools it doesn’t have built in. MCP is an open standard, originally released by Anthropic, that defines a common interface for exposing a database, an API, a file system or a piece of internal tooling to any agent that speaks the protocol, rather than writing a bespoke integration for every model you use.

Before something like MCP existed, connecting an agent to, say, your company’s ticketing system meant writing custom glue code for each model provider. With a shared protocol, the ticketing system exposes one MCP server, and any compliant agent (Claude, ChatGPT, Gemini, or something built in-house) can call it the same way. It’s the same problem USB-C solved for chargers, one connector instead of one per device.

Subagents

A subagent is a separate agent instance spawned to handle a self-contained piece of work, with its own context window, so it doesn’t pollute the parent agent’s context with intermediate steps. A parent agent might spawn a subagent to search a large codebase, summarise the findings, and hand back only the conclusion, rather than every file it read along the way.

This matters for two reasons. First, context is a limited resource, an agent that reads fifty files to answer one question shouldn’t carry all fifty files forward for the rest of the conversation. Second, it allows parallelism, independent subagents can run at the same time rather than one after another.

Agent to Agent

Agent-to-agent communication is what happens when multiple agents need to coordinate rather than one agent doing everything alone. Instead of a single model trying to be a researcher, a coder and a reviewer at once, you split those responsibilities across separate agents that message each other, each with a narrower job and its own context.

A simple pattern looks like this: one agent plans and delegates, other agents execute specific tasks and report back, and the coordinating agent decides what happens next based on those reports. This is different from a subagent doing a one-off lookup, agent-to-agent setups are often long running, with agents that can be resumed, sent follow-up instructions, or left running in the background while other work continues.

The tricky part isn’t the messaging, it’s deciding what information actually needs to cross the boundary between agents. Pass too little and the receiving agent lacks the context to make good decisions. Pass too much and you’ve just recreated one giant context window split across multiple processes.

Subagents assume a single vendor’s harness underneath. Real agent-to-agent work often crosses vendors entirely, which is what the Agent2Agent (A2A) protocol was built for. Originally developed by Google and now governed by the Agentic AI Foundation under the Linux Foundation, with Anthropic, OpenAI, Microsoft and AWS all backing it, A2A defines an open format for agents to advertise what they can do, hand off tasks, and exchange results, regardless of which model is running underneath.

Other ways to structure an agent

A few more patterns worth knowing, alongside the core ones above:

• Memory - persisting facts, preferences or task state across sessions, rather than starting from a blank context every time. Claude, ChatGPT and Gemini all now ship some form of this, letting an agent recall what it learned last week without being re-told.
• Plan mode / human-in-the-loop - having the agent propose a plan and pause for approval before it touches anything, useful for actions that are expensive or hard to reverse (deleting data, pushing code, spending money).
• Computer use / browser agents - instead of calling APIs, the agent controls a screen directly, clicking, typing and reading pixels, for the many tasks that don’t have a clean API to call.
• Guardrails and evals - automated checks that run alongside or after an agent’s actions to catch unsafe or low-quality output before it reaches a user, increasingly treated as a first-class part of the agent loop rather than an afterthought.

Claude, ChatGPT and Gemini in practice

The concepts above are shared across the industry, but each provider currently packages them a little differently.

Technique	Claude	ChatGPT / OpenAI	Gemini / Google
Agent framework	Claude Agent SDK (built on the Claude Code harness)	Agents SDK + AgentKit	Gemini Enterprise Agent Platform / Antigravity
Skills	Native Skills, loaded on demand (progressive disclosure)	Custom GPTs and tool configs cover similar ground, less formalised as “skills”	Extensions and slash commands in Gemini Code Assist
Subagents	Built in, each with its own context, tools and skills	Being added to the Agents SDK for Python and TypeScript	Multi-agent orchestration via Antigravity and Agent Registry
Long-running / background tasks	Loop-style scheduled runs, background sessions that resume with context intact	Background Mode for long-running tasks	Agent Runtime for persistent, long-running execution
Cross-agent communication	Native session-to-session messaging, plus A2A support	A2A support alongside its own Agents SDK handoffs	Originated the A2A protocol, deep first-party support
Tool integration	MCP support	MCP support	MCP support via Gemini Code Assist

Worth noting: this space moves fast, ChatGPT’s original “agent mode” was retired in 2026 in favour of ChatGPT Work, and Google folded several separate tools into the unified Antigravity platform in the same year. Treat any feature comparison, including this one, as a snapshot rather than a permanent fact.

Why this matters

None of these techniques are about making a model smarter, the underlying LLM is the same. They’re about giving that model better structure to work within, smaller focused contexts, reusable procedures, and the ability to break a large goal into pieces that can be delegated, looped over, or run independently. The more agentic tooling develops, the more the interesting engineering problems look less like prompting and more like distributed systems design.