Setting up your agents

You now know what an agent is: a model, some tools, and a loop that keeps it going until the goal is reached. With Claude Code, Codex or OpenCode freshly installed, you already have a perfectly functional agent, file system, terminal, git, search. But it’s the default agent, everyone’s agent. This guide is the step up to your agent: we enrich its tools, plug it into your data, and shape its behavior so it works the way you want.

Giving it more tools via MCP

The most powerful lever is called MCP: Model Context Protocol. It’s an open standard that has become the universal socket between an agent and the rest of the world. The idea: instead of coding a custom integration for each service, you add a small program, an MCP server: and the agent instantly gains a handful of new actions.

The concept is clearer with examples. Connect your agent to Postgres, and it can query your database directly: “how many orders yesterday?”, it writes the query and answers you. Connect it to GitHub, and it manages your issues and pull requests without leaving the terminal. Plug in a web search server, access to your file system, your ticketing tool, your own homemade service: each MCP server is another arm for the agent.

Claude Code, Codex and OpenCode all support MCP. In practice, you declare a server in your agent’s config (a name, a command to run, sometimes an API key), you restart, and the new tools appear. The common servers, filesystem, GitHub, Postgres, Slack, already exist; you write nothing, you just point to them.

What people actually plug in

The list of available servers grows every month. The most useful day to day:

The Meta server is a good case study, because it shows the value and the danger in the same gesture. An agent that queries it spots in three seconds that a campaign has been paused for two days, something a human only sees by opening the ads manager and looking in the right place. That same agent can restart the campaign, and spend your money.

Claude Design: when the output is not text

An agent produces code, files, messages. It can also produce visuals.

Claude Design is Anthropic’s mockup tool, in beta on the Pro, Max, Team and Enterprise plans. It lives at claude.ai/design, and Claude Code reaches it directly: the /design command followed by a brief (“/design a settings screen for a banking app”) has the agent draw on a canvas, several artboards laid side by side. You open the result in a browser, select an element, change it, and your edits save on their own. Each artboard exports to PNG or PDF.

The shift is in that handover. Fixing one visual detail produced by an agent used to mean rephrasing the request and hoping the rest stayed put. Here you adjust exactly what bothers you. It also works the other way: a finished mockup in Claude Design can be sent to Claude Code to be built, and /design-sync uploads your repo’s React component system so the mockups use your real components.

Useful for interface mockups, screen flows, a landing page, social graphics, a poster. Keep in mind it is a beta: the tool moves fast, and /design needs a recent version of Claude Code.

Sub-agents: delegate to stay clean

An agent can call on sub-agents: auxiliary agents that it launches itself, each with its own brand-new context and a precise mission. A sub-agent that goes off to dig through the codebase while the main one keeps going. A “reviewer” sub-agent dedicated to code review. A sub-agent that tests a hypothesis in parallel.

Why does this matter? For two very concrete reasons. First, it keeps the main context clean: the wide-ranging search through fifty files happens inside the sub-agent’s head, which only reports back the conclusion. The main thread doesn’t drown in details. Second, it parallelizes: three sub-agents working at the same time on three independent pieces is three times faster.

Claude Code formalizes this with sub-agents and custom agent types (an “explorer” agent, an “architect” agent…), each with its own tools and its own instructions, stored in .claude/agents/ (project) or ~/.claude/agents/ (global). The easiest way to create one: describe it to Claude, which writes the file. Codex works the same way: it spawns sub-agents (the /agent command switches between them), and your custom agents are small TOML files stored in .codex/agents/ (project) or ~/.codex/agents/ (global). We’ll cover the concrete patterns, when to delegate, how to frame a sub-agent, in the next guide. For now, just remember the capability exists: your agent isn’t alone, it can put together a small team.

Tightening permissions

This is the single most important setting, and the one most often neglected. An agent acts, so it can break things. Tightening its permissions means deciding which tools and commands it’s allowed to run freely, and which require your go-ahead. This is, very concretely, where you set the autonomy dial we talked about in the previous guide.

The building blocks are the same everywhere:

• The allowlist. You approve in advance the harmless, reversible actions: reading files, running the tests, doing a git status. The agent chains them without interrupting you.
• The “ask before X” rule. For anything that modifies or destroys, deleting, pushing to a remote branch, touching the network, installing a package, the agent stops and asks. This is the everyday setting: smooth on the harmless, cautious on the rest.
• Never root blindly. Never let an agent chain sudo commands without review. A badly formed privileged command doesn’t break a project, it breaks the machine.
• Confine the working directory. The agent works in your project folder and nowhere else. An agent that can only write under ~/projects/my-app can’t, even by mistake, touch anything elsewhere.

Config and memory

At startup, your agent reads its configuration and its memory files. That’s where the permanent instructions live: “this project uses pnpm, not npm”, “write commit messages in French”, “never touch the legacy/ folder”. You write it once, the agent remembers it every session, without you having to repeat it. That’s what turns a generic agent into one that knows your project and your habits.

We won’t detail it here, memory has its own complete guide, in Memory files. Remember the roles: config defines what the agent can do and with which tools, memory defines what it permanently knows about your world.

Claude Code, Codex and OpenCode, side by side

All three agents share the same philosophy, each with its own ecosystem. And they don’t offer the same models: Quelle IA’s coding tools page (in French) lists which models you’ll find in which tool (Claude Code, Codex, OpenCode, Cursor…), with each one’s score.

codex mcp add context7 -- npx -y @upstash/context7-mcp   # an MCP server launched locally
codex mcp list                                           # what's declared

The steps to follow

Here’s the checklist to go from the default agent to one tailored to you.

You now have an agent that’s like you: the right tools, the right data, the right limits. What’s left is learning to make it live in a real project: where to put the files, how the team shares the config, which sub-agent patterns work day to day.