If you’re still treating Continue.dev like a faster way to search your code, you’re missing the point. The open-source AI assistant has moved past the Q&A stage. With Continue.dev agents, you can build miniature specialists that inspect files, run commands, make edits, and keep going until a task is finished, not just reply once. They change the relationship between you, your IDE, and the AI model sitting behind it.
Meet Continue.dev: An Open-Source Coding Companion
Maybe you’ve already installed Continue in VS Code or JetBrains. It acts as a local bridge between your codebase and models such as GPT-4o, Claude, or Llama 3. Unlike cloud-locked assistants, Continue keeps your code on your machine unless you choose otherwise, and you bring your own API key. It reads the files you open and understands the whole workspace, which makes it ideal for tasks that require context.
A few years ago, Continue was mostly autocomplete and chat. But it has evolved into a kind of agentic coding platform. You can still ask one-off questions, but the heart of the newer workflow is the ability to spawn a custom agent, a self-contained worker with its own instructions, role, and tool access.
What Are Continue.dev Agents?
Think of an agent as a task-specific employee. It has a name, a description, a system prompt that sets its personality or expertise, and an instruction prompt that tells it what to do. The biggest step up is tool access. A Continue.dev agent can read local files, search your codebase, write to new files, and execute commands. It might even be allowed to run your test suite or linter. That’s what makes it different from ordinary chat.
In a classic chat turnaround, you ask a question and the model gives an answer. With agents, the model can sense the current state, decide which file to read next, then edit code and rerun the tests. You set the finish line, but the agent takes multiple shots at getting there. The output is not a wall of text; it is a changed repository.
You can also control how hands-on or hands-off each agent is. Some agents ask for confirmation before making changes. Others just produce a plan for you to approve. A few may need the ability to modify files freely, for example a scaffolding or formatting agent.
Why You Shouldn’t Just Keep One Generic Chat Prompt
Why add this complexity? Because a generic AI chat tries to be all things to all people. It is too easy to waste time re-typing context and caveats for every new conversation. A custom agent bundles all that context permanently under a name like Security Review or Test Generator.
- Consistency. Had a team standard for how to write migrations? Bake it into an agent. Every team member gets the same process.
- Speed. Switching to the right agent means not writing a five-line prompt every time. One click, and the task is running.
- Automation. Tedious parts of your job, like dependency upgrades or dead-code detection, can be run at the end of a sprint without tutorials.
- Reviewability. Version the agent config with your code. You see exactly what your agents have been told to do.
How to Build Your Own Continue.dev Agent
The best starting point is to copy an existing example instead of inventing from scratch. If you don’t have example agents in your config, go to the Continue documentation or GitHub examples. Copy an existing agent definition and adapt the name and prompt.
Most configurations will ask you to set these fields at minimum:
- Name and description. This is how you find the agent later. Use plain language like Changelog Writer or API Schema Checker.
- System message / persona. Write in the tone you want. For example, you are a meticulous code reviewer who always points out security risks first.
- Prompt template. This is the default instruction it receives. Be precise. Instead of improve this code, tell it to read the selected file, list maintainability problems, and propose a change in a diff.
- Tools list. Grant file reading, file editing, terminal execution only where necessary. If you want the agent to write tests, it needs write access. If you only want advice, leave that tool off.
Where do you put these? You will find your Continue config file in the .continue folder under your home directory or inside your project. The exact location may be config.json, config.yaml, or a TypeScript config depending on the version you run. When you save the config, the agent appears in the Continue sidebar. You can invoke it immediately.
If you are new to writing configs, make your first agent slightly boring. Build an agent that summarises the contents of a folder or points out TODOs in a file. The low stakes make it easier to experiment with prompt phrasing.
Five Useful Continue.dev Agents to Adapt Now
The list below isn’t theoretical. These are the kind of agents developers are creating to relieve pressure in their daily workflows.
- Pull Request Narrator. Reads the current git diff, summarizes each changed file, and lists the riskiest modifications. Useful for pre-review before you assign a human colleague.
- Test-Failure Autopsy Agent. When a test fails, this agent reads the stack trace, opens the relevant source files, and proposes a root-cause explanation. Some versions even suggest a minimal code change.
- API Refactor Planner. Hands it a deprecated endpoint and a target pattern. It walks through every caller, calculates downstream impact, and writes a migration checklist.
- Project Scaffolder. TypeScript project? Python CLI? This agent creates a directory layout, stub files, and skeleton config. It keeps you from flipping through boilerplate repositories.
- Dependency Upgrade Checker. Scans
requirements.txtorpackage.json, queries the latest versions, and runs a compatibility scan based on your code’s usage. The agent finishes with a list of upgrades sorted by risk.
Any one of these will give you a clearer idea of what an agent can do. Start with the Pull Request Narrator because it’s read-only and safe, then work your way up to agents that can modify files.
Design Principles for Agents That Actually Save You Time
A custom agent won’t feel like magic if you only copy a generic prompt. The best agents are opinionated. They know exactly when to stop, ask for confirmation, and produce output in a format your team can use.
First, limit the scope. An agent meant to write commit messages should not be scanning the entire codebase or looking for security bugs. Give it one job and a hard end condition like stop after you print the proposed message.
Second, spend 20 minutes on the system message. State the desired behaviour in precise terms. Tell the agent how to handle ambiguity, whether it should ask clarifying questions before editing, and what to do if a requested file is missing.
Third, keep your tools to a minimum. More tools make the agent smarter in theory, but in practice too much generative freedom causes the model to run unnecessary commands. Start with read and search tools, then add write only when your agent has proven safe.
Fourth, run your agent on a small example before deploying it on the entire repo. Ask it to process two files and inspect the diffs. If that works, let it loose on a larger task with your supervision close by.
Finally, put your agent definitions alongside your repo configuration and version them. When someone else opens your repo, they can see exactly which agents you intended to use. If an agent’s behaviour drifts after an update, compare the old definition in your commit history.
Continue.dev agents act like a shared toolbox for your specific coding practice. The more precise you are in the definition, the more work you can let go of. And as code models improve, your agent definition becomes leverage: a clearly written agent can outrun a much larger model that doesn’t know the goal.