The terminal has always been the wild west of my development workflow. It’s powerful, sure, but it’s also where context goes to die. I run a command, get some output, then manually translate that into something my team can actually act on. Maybe it’s just me, but I’ve spent way too many hours rewriting the same scripts, re-explaining our standards to new teammates, or trying to remember what that obscure grep command did last time.
That’s why when I first read about custom agents in GitHub Copilot CLI, something clicked. It’s not just another AI feature. It’s actually addressing a real pain point that most of us just accepted as “how it is.”
The Problem With One-Off Prompts
Here’s the thing about AI assistants in the terminal: they’re great at giving you answers, but they don’t really remember things. Ask Copilot CLI to generate a command, and it’s helpful in that moment. But next week when you need to do the exact same thing? You’re starting from scratch. Your team has standards, your project has conventions, and your organization has specific workflows, but each interaction treats you like a stranger.
I think this is why so many developers end up with a graveyard of bash scripts, random aliases, and half-documented procedures. We automate what we can, but there’s always that gap between “I know how to do this” and “the next person knows how to do this.”
Custom agents bridge that gap by letting you encode your team’s context directly into the CLI.
What Actually Makes Them Different
The key insight here is that these agents are defined as Markdown files living in your repository. Think about that for a second. Your team’s workflows, standards, and tool preferences become version-controlled artifacts that anyone can review, update, and share.
You’re not relying on some generic AI behavior anymore. You can tell an agent exactly what tools it has access to, what standards it should enforce, and what output format you need. Every single time it runs, it produces consistent, reviewable results.
For example, imagine you need to run security checks across your repositories. Instead of remembering which commands to run, what severity levels mean, and how to format the output for a pull request, you just invoke the agent. It handles all of that. Same checks, same tools, same output format, every single time.
The use cases they outline in the documentation make a lot of sense: security compliance reviews, release note generation, incident reporting, infrastructure policy validation. These are tasks that happen regularly in most teams but always feel like they require too much manual setup.
The Bigger Picture for Developer Experience
What strikes me most is how this shifts the relationship between developers and their tools. The terminal becomes less about executing commands and more about invoking workflows that understand your context. The CLI carries that context from your terminal into your IDE and eventually lands it in a pull request where your team can actually review what happened.
This is thedirection the industry has been moving toward anyway. Tools that remember what matters to your team rather than treating every interaction as an isolated event. It’s the difference between having a helpful colleague who forgets everything between conversations and having someone who’s actually paying attention to how your team works.
I also like that they’re releasing partner agents from companies like JFrog, Dynatrace, and Octopus Deploy. It shows they’re thinking about real workflows rather than just the coding part. Not everyone wants to build their own agent from scratch, and having off-the-shelf options that work with existing tooling lowers the barrier to entry significantly.
What’s Worth Considering
That said, I’m curious about how these agents will evolve in practice. Agent profiles are Markdown files, which means they’re readable and versionable, but they also need to be maintained. If your team’s standards change, someone has to update the agent definition and ensure it still works as expected. That’s not necessarily a problem, but it’s a new kind of technical debt to think about.
Also, there’s an interesting tension here between standardization and flexibility. The more you encode your team’s way of doing things into agents, the more efficient your workflows become. But you also risk making things too rigid, especially when someone joins the team and needs to understand not just what the agents do, but why they were configured that way.
For teams working with artificial intelligence tools, this pattern of encoding preferences into reusable workflows feels like it could become pretty common. The AI becomes more useful the more it understands about your specific context, and these agent profiles are essentially a way to teach the system about that context once rather than repeatedly.
Give it a few months and I suspect every team that takes developer experience seriously will have at least a couple of custom agents for their most repetitive workflows. The terminal’s getting smarter, and honestly, it’s about time.