Coder Legion - Recent posts tagged codingagents

Bito's Governor Cut Privado's Coding Agent Costs 48% by Ending the Search Loop

Tue, 27 Oct 2026 13:00:00 +0000

Coding agents cost more than they should, and the reason is easy to miss. Most of the bill isn't the work. It's the agent searching your codebase, then re-sending everything it found on every step.

Bito is launching Governor today to go after that cost. Governor is a gateway and model router for coding agents like Claude Code, Cursor and Codex. It does two things. It sends each request to the right model based on the task in progress, not just the newest message. And it gives the agent the code it needs up front, so the agent spends far less time searching.

Bito says it has measured savings of 40% to 70% across about 10 enterprise customers. In one test at Privado, cost per task fell 48%, from $4.12 to $2.14, and every task still succeeded.

I asked Amar Goel, co-founder and CEO of Bito, how Governor works, where it falls short, and what developers can do this week to cut their own agent bills. Answers have been edited for length and clarity.

The Problem

Your white paper says 60% to 80% of agent session cost goes to context gathering. What did you see that led you to build Governor around that problem?

A coding agent works in steps. It searches the code and gets back 10 to 50 results. It reads one file, then another. Only then does it start to plan or answer your question.

Every result gets added to the conversation. On the next step, the whole conversation goes back to the model, because the model keeps no memory between requests. In one Claude Code session we measured, the agent's searches returned about 65,000 tokens of code. By the end, the session had processed about 6 million tokens. Nearly all of it was the same material, re-sent turn after turn.

Routing alone lowers the price of each token. But the agent still searches and re-sends just as much, so the biggest part of the bill stays the same. If a router leans harder on cheap models to make up the gap, quality drops, and developers spend the savings redoing the work. So we built Governor to cut both the price per token and the number of tokens.

Why do keyword-based routers like LiteLLM and Bifrost struggle with coding-agent traffic?

In a coding session, the message that starts the hardest work is often the shortest, like "looks good, implement this." Its meaning comes from the conversation before it.

LiteLLM and Bifrost both pick a model by scanning the newest message for keywords. We ran 12 typical coding-agent messages through LiteLLM's scorer. It sent 11 of them to the cheapest model, including a one-line request to refactor authentication code everywhere it's called. A better keyword list won't fix that, because the scorer never sees the task behind the message.

Here's what that costs. A strong model reads the code and writes a plan. The developer replies "go ahead." A keyword router sends the build step to the cheapest model. The code comes back weaker, the developer sends it back for fixes, and the savings go into the redo. Governor reads the "go ahead" together with the plan it approves, so the build goes to a model strong enough to do it.

How It Works

Walk me through what happens to a request from Claude Code once it hits Governor.

When a developer starts a new request, Governor's classifier reads it along with the task in progress. It places the request in a tier based on the kind of work and what a mistake would put at risk. The tier sets the model and reasoning level, drawn only from models the customer allows.

Before switching models, Governor checks the prompt cache. That's the discounted copy of the conversation the provider already holds. Switching means paying to rebuild it, so Governor switches only when the next few requests will save more than the rebuild costs.

When the agent needs to find code, Governor's code retrieval sub-agent does the search. The main agent gets a short answer with the file and line each fact came from.

Governor keeps a live index of a customer's repositories. Where does it live, and how do you handle teams with strict rules about source code?

The index lives wherever the customer runs Governor, in Bito's cloud or on-prem. It's a structural index of the code across every repository. We don't store the source code itself, and none of it is used to train a model.

Teams with strict rules run Governor on-prem. The index, the lookups and the routing decisions all stay inside their network. Model requests go out on the customer's own provider accounts and keys, the same calls their agents already make. So an on-prem deployment adds no new party that sees the code. Bito is SOC 2 Type II certified.

How does Governor decide whether a request is Simple, Medium, Complex or Reasoning? And what happens when it gets one wrong?

The classifier asks two questions. What kind of work is this, and what would a wrong answer put at risk? Clear, stated changes, including carrying out a plan already agreed to, go to Simple. Vague requests go to Reasoning, because the first job is figuring out what the developer wants. We tested hundreds of versions of that rubric against hand-labeled requests. Early versions put about 60% of requests in the right tier. The current one gets all of them right, across repeated runs.

When it's wrong, guardrails limit the damage. By default, Governor never routes to a model pricier than the one the developer asked for. If it can't place a request, the requested model answers. If the classifier fails partway through a turn, Governor keeps the current model. Teams can pin work, like keeping all planning on Opus. And every request records why it went where it went, so a bad call is easy to find.

Switching models mid-session throws away a paid-for cache. How does Governor decide when moving is worth it?

A warm cache can make the expensive model the cheaper choice. Reading a cached Opus 5.5 conversation costs $0.20 per million tokens. Sending the same conversation to Gemini Flash with nothing cached costs $0.75.

Over a longer stretch, the math can flip. In one 48-request implementation loop, paying once to warm the cheaper model's cache would have cut the cost by a third. The obvious answer is to forecast how long the conversation will run. That's very hard, though we're working on it.

So Governor asks a smaller question it can answer: will the next few requests pay back the cost of moving? It moves only when they will, so a wrong call costs at most a few requests' worth of savings. When we replayed real conversations, a forecast-based rule added 42% to the bill in one case where Governor's rule lost nothing.

The Results

The launch headline says 40% to 70% savings. Where does that range come from, and where should teams start?

We've measured results across about 10 enterprise customers so far. Savings vary because some customers pick Balanced and some pick Cost, and their workloads differ. The longer your coding sessions, the more you save. If you run a lot of short sessions, the savings are smaller. Some customers are getting around 80%, but we didn't want to overpromise.

Here's how the settings compare with Claude Code's default on Opus 5.5 in our long-session benchmark:

Quality keeps the same score at 1.3x lower cost, about 23%, with sessions 12% faster.
Balanced keeps 95% of the score at 1.9x lower cost, about 47%, with sessions 39% faster.
Cost keeps 94% of the score at 7.1x lower cost, about 86%, with sessions 30% faster.

These are benchmark numbers, so treat them as a starting estimate for your own traffic.

I'd start every team in shadow mode, where Governor records what it would have done without changing anything. Then switch on Balanced with planning pinned to the strongest model. Planning is what everything else in a session builds on, so that's where the best model earns its price.

Tell me about the Privado test.

Privado builds a privacy engineering platform, and its developers work in Claude Code. They ran 40 of their own engineering tasks twice, once straight to the model and once through Governor. Same model, same agent setup, so Governor was the only variable.

Cost per task fell 48%, from $4.12 to $2.14. Every task succeeded both ways. With Governor, tasks finished 38% faster. The agent took half as many reasoning turns and made 53% fewer tool calls, because it spent far less time searching the code.

For the developers, nothing changed in how they worked. They kept their agent, their prompts and their workflow. The difference showed up in the bill and in how fast tasks came back.

The benchmarks are Bito's own. What should a skeptical engineering lead know?

We built both benchmarks so a model can only score well by doing the work. Our public study graded 1,800 answers from 30 models on 60 real engineering tasks. Twenty-six run on private code no model could have seen in training. Twenty-eight are graded by running the model's code, so an answer counts only if it works. The session benchmark uses long Claude Code sessions on proprietary code, graded against a written key. Identical sessions vary by 1.5 to 2 points, so we compare averages and read every session that falls well below.

Still, a skeptical lead should trust their own traffic over our numbers. Shadow mode shows what Governor would have done. A/B mode sends a small share of traffic around Governor, compares cost per task, and grades a daily sample with a judge from a different model provider than the one doing the work.

Where does a cheaper setting lose quality, and how should a team protect those steps?

The loss sits in specific steps, not across the whole session. In our benchmark, Balanced fell furthest behind on diagnosing a failure. It earned 67% of the available points on that step, against 90% for the Opus 5.5 default. Quality scored 93%. Cheaper settings also lost points when defending a design against pushback.

Teams can protect those steps by keeping them on the strongest model. Governor lets a team route specific kinds of work up, so diagnosis and design review stay on Opus while the rest of the session runs on Balanced.

Trade-offs and Limits

Code context adds a wait before the first answer. When does it pay off?

Code context takes about 30 seconds up front. But that time isn't new. In our benchmark, Opus 5.5 on its own spends 36 to 41 seconds grepping and reading code before it starts the real work. Governor does that research for the agent, and tasks finish much faster overall.

On one benchmark of real developer requests, including tracing an event through Kafka and planning a feature, the session took 8.5 minutes with code context versus 25 minutes without. The agent made 14 tool calls instead of 162.

It pays off least on short, well-defined tasks, where the agent already knows where to look. It also helps less on steps that depend on reading one edge case line by line. That's what we're working on next.

What doesn't Governor do well yet?

There are four things, and we list them in the paper. First, short tasks. Some levers, prompt guidance in particular, add a fixed overhead that cancels most of the saving on quick jobs. So the Quality setting costs about the same as today on short work.

Second, cache behavior on some providers. With certain cheap models, the cache rule kept nearly every request on the expensive model, which leaves little saving.

Third, Governor decides fresh at the start of each turn. It doesn't forecast where a session is heading, which would help it pick models earlier.

Fourth, it can capture what developers do after an answer, but using that to tune the rubric for each team is still a manual step.

Getting Started

What does setup look like?

It's a base URL change in your existing coding agent. Governor speaks the Anthropic and OpenAI APIs, so pointing Claude Code, Cursor or Codex at it is one environment variable. Requests keep their model, streaming and tool calls. It runs on the team's own provider keys, alongside any gateway they already use, in Bito's cloud or on-prem. For code context, the team connects the repositories Governor should index.

Shadow mode records from the first request. A team can be up and running in minutes.

Which agents and providers are supported, and how is Governor priced?

At launch, Governor works with Claude Code, Cursor, Codex, GitHub Copilot and Pi, plus any agent that calls the Anthropic or OpenAI APIs. It covers Anthropic, OpenAI, Gemini (including on Vertex), Grok and open-weight models, on the customer's own keys or through their existing gateway.

Pricing is usage-based, scaled to the size of the indexed codebase and the volume of routing requests. Model provider costs pass straight through, so the savings show up on the bills teams already pay. Every team starts with a free trial on its own agents.

If a developer wants to cut agent costs this week, with or without Governor, what's the first step?

Look at one long session from your team, token by token. Most teams find the bill is the conversation being re-sent, with the agent's own searches piling up, more than the work itself. Across our model research, cache reads were 77% of all tokens processed.

Then check the reasoning level your tools send. Most send the same level on every request. On our benchmark, lighter reasoning on Sonnet 5.5 saved 9% and kept 98% of the score. And keep planning on your strongest model, since everything after it builds on the plan.

With Governor, start with shadow mode on your own traffic.

The Takeaway

The useful idea here goes beyond routing. Most of a coding agent's bill comes from what it re-reads, not what it writes. Cut the searching and the re-sending, and the choice of model matters less. Bito's numbers are its own, so the right first move is the one Goel suggests: measure one session from your own team and see where the tokens go.

HiddenLayer: A Hijacked LLM Gateway Can Turn Your Coding Agent's Own Permissions Against You

Thu, 22 Oct 2026 14:00:00 +0000

Most security talk about AI coding agents focuses on the model. Will it run a bad command? Can a poisoned README trick it? New research from HiddenLayer looks somewhere else: the plumbing between the agent and the model.

In a report released today, HiddenLayer researchers Esteban Tonglet, Divyanshu Divyanshu, and Kasimir Schulz show that anyone who controls an inference server or LLM gateway can quietly learn how a coding agent is configured. Then they can forge tool calls that ride on permissions the developer already granted. The agent runs them. The developer sees nothing unusual.

Why the middle layer matters

Plenty of developers don't send traffic straight to one vendor. They use open harnesses like OpenCode, Cline, and Hermes, pointed at open-weight models served through Ollama, vLLM, or providers like Together AI and Fireworks. Many organizations add a gateway such as LiteLLM to centralize API keys, routing, logging, and policy.

Each layer relays requests and responses, so it sees prompts, tool definitions, history, and tool output. LiteLLM's async_pre_call_hook and async_post_call_success_hook let custom code read or rewrite that traffic. That's useful for guardrails. It's also exactly what an attacker wants.

HiddenLayer describes two ways in: a malicious Ollama wrapper that listens on the default port, 11434, and forwards to the real service, or a supply chain compromise of a gateway's package, plugin, or container image.

Step one: watch the clock

The attacker doesn't need to change anything to start learning. By timing the gap between a tool call and its result, a proxy can tell whether the agent paused for a human to approve it. File reads normally finish almost instantly. A pause of several seconds suggests a prompt.

The signal is strong. Across more than 4,000 captured sessions, just 4.7% of calls to fast tools landed in HiddenLayer's ambiguous range, compared with 25.5% of shell calls. Across more than 35,000 file reads, only 1% did.

Shell commands are noisier. So the proxy can slip timing code into a script through an auto-approved file edit, or wrap a command in a timer. Either way, the timing output is stripped before the user sees it.

Hiding that wrapper is easier than you'd think. Agents routinely generate long build commands full of pipes and redirects. Users scan for rm, sudo, or curl piped to a shell. A small addition in a 20-command line blends in. The researchers used a Tree-sitter Bash parser to score complexity and pick hiding spots.

Step two: read the configuration

Harnesses also give a lot away. Codex headers start with codex-tui. Claude Code identifies itself as claude-cli. Hermes uses a generic OpenAI SDK user agent, but its default tools (terminal, write_file, patch) reveal it.

Some harnesses go further. Codex includes its permission settings in every request: sandbox mode, writable paths, network access, and approved command prefixes. Claude Code sends its working directory, OS, Git status, and a Bash tool schema that includes a dangerouslyDisableSandbox option.

A proxy can also insert its own reads of files like CLAUDE.md, AGENTS.md, or .cursorrules, then strip the call and result. The model never knows.

Step three: use what's already allowed

HiddenLayer ran two demos. In the first, Hermes ran in manual mode, which only prompts for commands it considers dangerous. When the user asked Hermes to read a Python file, the proxy inserted file edits that added a heartbeat_ok() function. That function collected environment variables and SSH keys and sent them to an attacker's webhook. The proxy then ran the file with python3 and removed the function. Every step ran without a prompt.

In the second, Codex had the git prefix approved and a writable .git directory. The proxy forged this call:

git -c diff.external='sh -c "cat .env"' diff --no-index /dev/null .env

Codex ran it without asking and returned the contents of .env. Git's helper options can launch other programs, so an approved git prefix is broader than it looks.

There's a slower option, too. The gateway rewrites a dependency name, say requests to reqiests. Nothing happens until someone installs dependencies later.

This isn't hypothetical

LiteLLM shipped two malicious PyPI versions, 1.82.7 and 1.82.8, on March 24, 2026, after attackers got hold of a maintainer's publishing credentials. And an April 2026 study of 428 third-party LLM routers by University of California researchers found nine injecting malicious code and 17 abusing researcher-planted AWS credentials.

What developers can do now

HiddenLayer's report focuses on the attack, not a checklist. Here's what I'd take from it:

Treat gateways and inference servers as part of your trust boundary. Pin versions, verify artifacts, and control who can change hooks and callbacks.
Be careful with free or unknown routers. Cheap access isn't worth handing someone your traffic and keys.
Keep approvals narrow. Blanket approvals for git, python, or file edits give a proxy room to work.
Keep secrets out of the agent's reach. Don't leave .env files, SSH keys, or cloud credentials where the agent can read them.
Watch outbound traffic from developer machines and build systems.

Coding agents are doing a lot of good work. But sandboxes and approval prompts assume each tool call came from the model you chose. HiddenLayer's point is that this assumption no longer holds. The security boundary includes every system that can shape what the agent runs. And the teams that build and deploy these agents are responsible for that whole path.

We Were Going to Get Rich with One Prompt — PR #3217

Wed, 30 Sep 2026 20:35:27 +0000

At first, I was caught up in the hype too.

Like many people, I imagined that I could write a prompt, generate something, make money from it — maybe even get rich overnight.

But before I started, I asked myself a simple question:

If writing software, building applications, and coding can make you rich, shouldn't every software developer be rich?

Looking at reality, that clearly wasn't the case.

So I put that thought aside.

My real goal was simply to see what I could actually do.

I started experimenting.

One prompt.

The result: a pile of code that didn't work.

Another prompt.

Same result.

Two, three, four attempts...

Nothing changed.

That was my first important realization:

AI wasn't perfect.

More importantly, I couldn't believe everything it told me.

It could tell me that it had built something that worked.

But in reality, it didn't.

My second realization was more personal:

Simply prompting AI to build something wasn't possible for me — at least not at that stage.

I had two choices.

Give up.

Or figure out how to make it possible.

I chose to learn.

But I didn't take the traditional route.

I didn't want to spend months watching software engineering courses, programming lessons, and AI courses.

I needed a different way of learning.

So I started working like a bee.

A bee doesn't carry the whole flower back to the hive.

It takes what it needs.

Then it goes back to the hive.

I started doing the same thing.

Whenever I wanted to build something, I focused on what I needed to learn at that moment.

I found the information.

I read it.

I tried it.

If it didn't work, I researched again.

Then I tried again.

I didn't learn in order to build.
I learned while building.

And over time, it started working.

I learned GitHub.

Branches.

Commits.

Repositories.

Then the terminology of software development.

Then I started understanding the AI tools and coding agents I was using.

I didn't try to learn everything at once.

I learned whatever I needed to solve the problem in front of me.

And eventually, I started getting my first results.

They were simple things.

But they mattered.

Because I was no longer just writing a prompt and waiting for AI to produce something.

I was building something, trying to understand what it had actually done, investigating why it failed, and trying again.

Then I noticed something else.

The more I used AI and coding agents, the more I started seeing their problems.

Where an agent failed.

Why it kept repeating the same mistake.

What information it forgot.

And why, when I switched to another agent, I had to explain everything all over again.

At some point, I thought:

Maybe instead of constantly fixing agents' problems, I could build tools to solve those problems.

One of the first projects that came out of this was LEVH.

When I was using multiple AI agents, I kept running into a very simple but frustrating problem:

Every agent started each session from zero.

I could spend days giving one agent context about a project.

We would make decisions.

Define rules.

Solve problems.

Then, because of context limits or simply because I needed to use another tool, I would switch to another agent.

And start all over again.

Explain the same decisions.

The same rules.

The same problems.

Everything.

That started to feel ridiculous.

Instead of waiting for agents to become smarter, I asked:

Why can't they share a memory?

So I started building LEVH.

Today, LEVH is a local-first memory layer that gives different AI tools and agents on the same machine access to persistent shared memory.

I still use it myself.

And I'm still developing it.

[LEVH — GitHub repository][https://github.com/ali-ulu/levh]

Feel free to use it, explore it, and contribute if you find it useful.

But LEVH taught me something else:

Sometimes the real value of working with AI doesn't come from seeing how good its answers are.

It comes from noticing where it fails.

The more problems I saw in agents, the more small tools I started building to solve them.

And eventually, that led me to another question:

What if we could control not only an agent's memory, but also what it does?

That question led me to HUQAN.

And that's where the next part of the story begins.

I have not failed. I've just found 10,000 ways that won't work -Edison

  http://github.com/ali-ulu/levh

Build or Buy: The Agent Platform Decision Developers Face in 2026

Thu, 15 Jan 2026 03:44:18 +0000

You need an agent to handle code reviews. Or automate testing. Or manage deployments. Or debug production issues.

The question comes up immediately: do we build it or use a platform?

The honest answer is uncomfortable: it depends on your team, your constraints, and what you're trying to accomplish.

Elite developers building custom agents get better results for their specific use cases. But most teams ship faster and maintain easier with platforms.

Here's how to decide which path makes sense for your situation.

The 10x Developer Pattern

There's a pattern emerging among developers who get exceptional results with AI agents. They're not waiting for perfect platforms. They're building modular, specialized agents for their exact workflows.

One AI architect described it clearly: "The 10x developers are building these modular, swappable architectures today. They create specialized bots for different tasks—research, analysis, visualization—then build orchestration layers that let them work together."

This approach works because these developers understand their workflows intimately. They know exactly what bottlenecks exist. They can design agents that solve their specific problems.

The agents they build aren't general-purpose. They're laser-focused on particular tasks in particular contexts. That specificity is what makes them powerful.

But this approach requires significant investment. You need to understand agent architecture. You need to build orchestration logic. You need to maintain everything as AI capabilities evolve.

For teams with those capabilities and unique requirements, building custom agents delivers better results than any platform.

When Building Makes Sense

Build custom agents when you have:

Unique workflows that platforms don't support. If your development process is highly specialized—custom tooling, proprietary systems, unusual constraints—platforms built for common patterns won't fit well.

Specific security or compliance requirements. If you can't send code or data to external services, or you need specific audit capabilities, building gives you full control.

Integration needs platforms don't handle. If you need agents that work with internal systems platforms don't support, custom building makes sense.

Engineering capacity to maintain agents. Building is the easy part. Maintaining as models improve, platforms evolve, and requirements change is harder. Only build if you can maintain.

Clear ROI from customization. If the benefit of perfectly tailored agents significantly outweighs platform costs plus your engineering time, build.

The key insight: building is about control and specificity. You get exactly what you need. But you pay for it in engineering time.

When Platforms Make Sense

Use platforms when you have:

Common workflows that platforms handle well. If you're doing standard code completion, testing, documentation, or debugging, platforms are optimized for these patterns.

Need to ship quickly. Platforms get you results in hours or days, not weeks or months. If speed to value matters more than perfect fit, use platforms.

Limited engineering capacity for agent maintenance. Platforms handle model updates, capability improvements, and integration maintenance. You focus on using agents, not maintaining them.

Standard security requirements. If you can use external services with standard security practices, platforms work fine.

Uncertain requirements. If you're still figuring out what you need, platforms let you experiment without big upfront investment.

The pattern: platforms trade some flexibility for speed, ease of use, and lower maintenance burden. For most teams, that's the right tradeoff.

Platform Capabilities That Matter

If you're evaluating platforms, focus on capabilities that actually impact results:

Response speed. Cursor 2.0's Composer model completes most tasks in under 30 seconds. That matters. When AI takes several minutes to respond, it breaks your flow. Fast feedback keeps you productive.

Codebase understanding. Asimov from Reflection AI is designed specifically for deep codebase comprehension. It ingests entire codebases, architecture docs, GitHub threads, and chat history to understand context. For large, complex projects, this depth of understanding matters more than raw generation speed.

Multi-agent support. Some platforms let you run multiple agents in parallel on different tasks. This matters when you're working on several problems simultaneously or when having multiple agents attempt the same task improves results.

Code execution and testing. Platforms that can actually run code and test changes deliver better results than those that just generate suggestions. Being able to verify that code works before suggesting it reduces iteration cycles.

Integration with your tools. Check what your platform integrates with natively. GitHub? GitLab? Your internal systems? The fewer custom integrations you need to build, the faster you ship.

Comparing Real Options

Here's how current platforms compare on key capabilities:

GitHub Copilot coding agent handles task delegation well. You describe what you want, it works in the background, creates draft pull requests. Good for defined tasks you can hand off. Integrates deeply with GitHub workflows.

Cursor 2.0 focuses on speed and multi-agent workflows. The Composer model is fast. The parallel agent capability lets you try multiple approaches simultaneously. Good for rapid iteration on code tasks.

Asimov excels at understanding large, complex codebases. It's built specifically for the research phase of development—understanding existing code before making changes. In blind tests with open source maintainers, it beat other coding products 60-80% of the time on complex questions.

Shadow is open source with MIT licensing. It creates isolated execution environments where agents can work autonomously on GitHub repositories. Good if you need full control and don't mind managing infrastructure.

Each platform optimizes for different use cases. The best choice depends on what you're trying to accomplish.

The Cost Calculation

Cost isn't just subscription fees. It's subscription fees plus engineering time plus opportunity cost.

Platform costs are straightforward. GitHub Copilot, Cursor, and similar platforms cost $20-40 per user per month. Multiply by your team size. That's your direct cost.

Build costs are trickier. How much engineering time to build the initial agent? How much ongoing maintenance? What's that time worth?

If it takes two engineers two weeks to build a custom agent, that's roughly $10,000-20,000 in engineering cost depending on salaries. Then add maintenance time. And opportunity cost—what else could those engineers have built?

Compare that to a year of platform subscriptions. For a 10-person team using Cursor at $30/month, you're looking at $3,600 annually.

The math gets interesting when you factor in benefits. If your custom agent delivers 10% better results because it's perfectly tailored to your workflow, does that 10% improvement justify the engineering investment?

Sometimes yes. Often no.

Integration Points That Matter

Whether you build or buy, certain integration points determine success:

Version control integration. How do agents access your repository? Create branches? Submit pull requests? This needs to be seamless.

CI/CD integration. Can agents trigger builds and tests? See results? This matters for agents that verify their work.

Observability integration. For agents handling production issues, they need access to logs, metrics, and traces. How does this work?

Internal tool integration. Your team probably uses internal tools that platforms don't know about. How do you handle this?

Data access. What data can agents access? What's off limits? How do you enforce boundaries?

Platforms handle common integrations well. Custom agents let you integrate with anything but require you to build those integrations.

The Hybrid Approach

You don't have to choose one path exclusively. Many teams use platforms for common tasks and build custom agents for specialized needs.

Use GitHub Copilot for general code completion and pull request reviews. Build a custom agent for your specific deployment workflow that platforms don't understand.

Use Cursor for rapid prototyping. Build custom agents that integrate with your internal monitoring systems.

Use Asimov for codebase research. Build custom agents for your compliance reporting that needs to work with proprietary systems.

The hybrid approach lets you get platform benefits for commodity tasks while maintaining control where it matters.

What's Changing Fast

The platform landscape is evolving quickly. GitHub Copilot added background task delegation this year. Cursor launched multi-agent capabilities. Asimov launched focused specifically on codebase comprehension.

If you build custom agents, you control the pace of change. You upgrade when you're ready. But you might miss capabilities platforms add.

If you use platforms, you get new capabilities automatically. But you're dependent on platform direction and timing.

This tradeoff matters for teams in rapidly changing environments. Can you afford to wait for platforms to add capabilities you need? Or do you need control over your roadmap?

The Build Decision Checklist

Before deciding to build, honestly answer these questions:

Do we have engineers with agent architecture experience? Building agents is different from building applications. Do you have the skills?

Can we maintain this long-term? Models improve. Best practices evolve. Can you keep your custom agents current?

Is our use case truly unique? Or are we overestimating how special our needs are? Many "unique" workflows turn out to be common with slight variations.

Have we tried platforms and found them insufficient? Or are we building because building is more fun than configuring?

Will the team actually use custom agents? Sometimes custom-built tools don't get adopted because they lack polish or documentation.

If you answer yes to all of these, building might make sense. If you're uncertain on any, start with platforms.

The Platform Selection Checklist

If you're going with a platform, evaluate:

Does it handle our primary use cases well? Test it with real tasks your team does daily.

How fast is the feedback loop? Slow responses kill productivity.

What's the codebase size limit? Some platforms struggle with large repositories.

Can it integrate with our tools? Check GitHub, GitLab, whatever you use.

What's the pricing model? Per-user, per-usage, or hybrid? Which makes sense for your team size and usage patterns?

What data leaves our environment? Understand exactly what gets sent to platform providers.

How good is the support? When things break, how quickly can you get help?

Test platforms with real work before committing. Most offer trials. Use them.

Start With Platforms, Build When Needed

The practical advice for most teams: start with platforms.

They get you results quickly. They're easier to adopt across a team. They handle maintenance. And they're improving fast.

If you hit real limitations—not imagined limitations, real ones that platform support can't solve—then consider building custom agents for those specific use cases.

The elite developers building custom agents? Many of them spent years using platforms first. They understand what works and what doesn't. They build custom solutions to fill specific gaps platforms don't address.

You don't need to start where they ended up. You can reach the same place by starting with platforms and building strategically when you hit real constraints.

Building Is Glamorous, Platforms Deliver Value

There's something appealing about building your own agents. Custom architecture. Perfect fit for your needs. Full control.

But there's also something valuable about solving problems quickly with tools that already exist.

The question isn't which is better in the abstract. It's which is better for your team, your constraints, your timeline, and your requirements.

Most teams get more value from platforms. Some teams genuinely need custom solutions. A few teams benefit from both.

The key is being honest about which category you're in.

If you're not sure, start with platforms. You can always build custom agents later when you have clear evidence you need them.

But if you build first and regret it, you've spent weeks or months of engineering time with nothing to show for it.

Start fast. Build selectively. Ship constantly.

That's how you make real progress with agents in 2026.