🛠️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 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, in two years, 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 and OpenCode both 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.

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. 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, not across the whole file system. 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 and OpenCode, side by side

Both agents share the same philosophy, but not the same ecosystem.

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.