Language model–based agents are increasingly used to not just generate text, but to take actions: call APIs, run commands, read and write files, and update databases. Many setups today assume that if an agent has a capability wired in, it is allowed to use it. The default behavior is often to perform actions whenever the agent decides they’re helpful.

These actions can be simple, like fetching something from an external URL, or more impactful, like running commands locally on a machine or updating files and databases. From a usability perspective this can look appealing: you ask for something, and the agent goes ahead and does it. But this action-first default hides important risks and makes systems harder to control.

A safer baseline is that the default agent behavior should be: perform no actions. An agent should start in a mode where it can read, reason, and suggest, but not execute anything that changes the outside world. Any action it is allowed to take should be explicitly configured and explicitly permitted.

In practice, this means that which actions can be executed must be set up deliberately. Tool use, external calls, command execution, and write access should all be treated as opt-in capabilities. If a system wants an agent to be able to fetch a URL, run a specific command, or update a certain database, that must be granted explicitly, not assumed because the agent technically can do it.

This follows a zero trust mindset for agents. Do not assume an agent is allowed to act just because it has access to a tool. Assume no action is allowed by default, and then selectively enable narrowly scoped capabilities with clear permissions and boundaries. This makes it easier to reason about what an agent can do, reduces the risk of unintended changes, and keeps control in the hands of the people designing and operating these systems.

When you build agents with language models, it’s very tempting to go straight for the most powerful models. These are usually delivered by the biggest providers, running in their data centers, with impressive capabilities and benchmarks. That can be a great choice for experimentation and early prototypes, where you want to see what is possible as quickly as you can.

But when you want agents to automate work at industrial scale, as part of important processes, the priorities start to shift. Having the newest and “best” model is not necessarily the most important thing anymore. Instead, stability and predictability become more critical.

In many settings, it matters that the result is always the same. If the agent is part of a core workflow, even small inaccuracies can become a real cost. Service interruptions or changes in behavior can cause delays, errors, or force people to step in manually. When that happens in an industrial context, it is not just an inconvenience; it is a business problem.

Using powerful models from large providers also means tying yourself to a service you don’t control. The provider can update or change the model at any time. The same prompt might suddenly produce a different result because the model was upgraded. That might be fine in a demo, but it is risky in a production process that depends on consistent behavior over time.

In these situations, self-hosted or more tightly controlled models can be a better alternative. With your own infrastructure, or with providers that prioritize stability, nothing changes without testing and approval. You decide when to update a model, you can verify the impact of changes before they reach production, and you can roll back if something breaks. The focus is on predictable behavior rather than constant evolution.

This leaves you with a clear strategic choice. You can use the most powerful and newest models and accept that the service can suddenly change in production. Or you can go for stability and predictability by using other types of providers or self-hosted solutions, where you control when and how things change.

For agents that are part of critical, industrial-scale processes, the question is less “What is the most powerful model available?” and more “What behavior can I rely on, day after day, without surprises?”

In many organizations that adopt agents and language models, a clear pattern appears: about 1% of users consume roughly 90% of the resources. A few people run most of the prompts, build most of the automations, and drive most of the costs. Yet these resources are often not used well—they don’t generate new value or new “resources” for the organization.

This is the usage pattern many companies see with agents and language models. A small number of users use them very heavily. It costs a lot. And there is no obvious, measurable benefit. You get bills and usage graphs, but not clear gains in efficiency, revenue, or quality.

So what are these heavy users actually doing? Are they very inefficient? Are they creating large amounts of unnecessary automation? Are they mostly testing and experimenting? Or are they simply wasting resources? In many cases they are building and trying things without clear goals or success criteria. They create workflows that nobody else adopts, or they use agents as personal helpers without turning that into shared improvements for their team.

When heavy usage doesn’t create new value, the organization ends up funding exploration without getting much back. The agents and language models are used a lot, but not in ways that change core processes or free up time. Experiments remain experiments, and the rest of the organization barely notices.

A useful way to test this is to ask: what happens when these heavy users stop using agents? If that 1% stopped tomorrow, would the need for resources fall sharply? Would the organization’s demand for agents almost disappear? If so, it suggests that most usage was driven by a few enthusiasts, not by broad, sustainable use cases. The tools were not embedded deeply into everyday work.

To understand if you have this problem, look at how usage and costs are distributed. Identify who the heavy users are and what they use agents for. Check whether their work leads to concrete outcomes, such as time saved, fewer manual tasks, or improved key metrics. Ask how much of their activity becomes shared, production-ready workflows, and how much stays as personal experiments.

Heavy users can be valuable—they are often the ones who explore possibilities and build first versions. But their energy needs direction. Instead of open-ended usage with no clear benefit, their work should be tied to specific problems and processes. Experiments should either be turned into stable solutions or consciously stopped. Otherwise, the organization risks a situation where 1% of users burn 90% of the budget, without creating new value in return.

The goal is not to shut down these users, but to make sure their efforts generate real, lasting benefits. When agents and language models are used in ways that create new resources—saved time, better decisions, improved workflows—the high consumption can be justified. When they are not, it is a sign that usage needs to be aligned more closely with the organization’s actual needs.

In many situations there are more wrong choices than right ones. That means it’s easier to choose wrong, easier to make mistakes, and easier for things to go wrong. This can feel frustrating, but it also creates an opportunity: even if you are not good at choosing the right option immediately, you can still make progress by learning which options are wrong and eliminating them over time.

When the number of wrong options is large, mistakes become a natural part of how you learn. Every wrong choice shows you something: this does not work, this does not fit, this is not the right path. Step by step, you build knowledge around what is a bad choice, even before you fully know what the right choice is.

You don’t need to be good at choosing correctly from the beginning. You can start with a set of possible options, try them in small ways, and pay attention to what clearly doesn’t work. Each time you recognize a wrong choice, you can remove it from your list. By gradually eliminating wrong choices, you reduce the chance of making the same mistake again.

Over time, the number of bad options shrinks. That alone makes it more likely that you will end up making better decisions. You are not suddenly perfect at choosing; you have simply removed many of the ways to choose badly. In a world with more wrong choices than right ones, this is a practical way to move forward: treat wrong choices as information, use them to narrow the field, and let the space of possible mistakes become smaller and smaller.

When people start with automation, they often pick the most complex or “interesting” parts of their work. That can feel appealing, but it rarely gives the best return. A more practical approach is to first automate the parts of a process that repeat often and need to be done many times.

You should look for tasks that come up again and again. These are the actions you perform every day or several times a week. They are usually predictable, a bit boring, and you can almost do them on autopilot. Even if each instance is quick, the total time spent adds up.

On the other hand, you can wait before you automate tasks that are quite static and done rarely. These are things you set up once and then hardly touch. They might be important, but because they do not repeat much, you will not gain that much by automating them first.

A simple example is a testing workflow in software development. One part is writing the code for a test. Another part is evaluating the result of a test run. Writing the test code typically happens once per test and is updated infrequently. Evaluating the test result happens every time the test runs.

From a practical point of view, it makes more sense to first automate the evaluation of test results, because it is repeated many times. Automating the creation of test code can still be useful, but since it is done once and updated rarely, it is usually a weaker candidate for your very first automation efforts.

So, when you decide what to automate, start by asking: what do I do most often, and what follows clear, repeatable steps? Automate those parts first, and postpone the work that is static, infrequent, and more one-off in nature

Software engineering has evolved rapidly over the last decade. We have excellent tools for writing code, managing source control, tracking issues, deploying software, and monitoring production. Yet the engineering process itself remains fragmented across dozens of disconnected applications and manual handoffs.

At the same time, AI has introduced a new opportunity. Specialized agents can assist engineers throughout the software lifecycle—not only by writing code, but by helping define requirements, design solutions, review changes, generate tests, automate releases, and monitor production systems.

DevBench brings these ideas together.

One workbench for the entire engineering lifecycle

DevBench is a software engineering workbench that supports the complete lifecycle of software development:

• Requirements and change specifications
• Solution design
• Implementation
• Software change review
• Testing
• Release
• Production monitoring

Rather than treating these as isolated activities, DevBench connects them into a continuous engineering process.

The illustration below shows the concept. The software engineering lifecycle forms the outer cycle. At the center is DevBench, providing a unified workspace for projects, documentation, code, and automation. Surrounding the workbench are specialized engineering agents, each supporting a particular stage of the process.

Illustration: DevBench orchestrates the complete software engineering lifecycle with specialized engineering agents.

AI that supports engineering—not replaces it

DevBench is not another coding assistant.

Instead, it is a platform where organizations can build, customize, and orchestrate engineering agents that work alongside development teams. Each agent has a well-defined responsibility, from refining requirements to reviewing pull requests or monitoring production systems.

Engineers remain in control. The agents automate repetitive work, provide recommendations, maintain consistency, and ensure traceability across the entire lifecycle.

A platform for engineering organizations

Beyond supporting the process, DevBench provides the foundation for modern software engineering teams:

• A single source of truth for specifications, architecture, documentation, and code
• Configurable engineering workflows
• Customizable engineering agents
• Integration with existing development tools and repositories
• End-to-end traceability from requirements to production
• Continuous learning from engineering practices and project history

Building the future of software engineering

Software engineering is becoming increasingly collaborative—not only between people, but between people and intelligent tools.

Our vision for DevBench is simple:

Create a single workbench where software is engineered from idea to production, with specialized agents supporting every step of the journey.

When you consider whether you can trust a control agent, it helps to start with a simple, practical question: what is the alternative? The goal is not to decide if the agent is perfect, but whether it is good enough compared to what you have today.

A control agent here means a system based on a language model that performs checks or controls of something. It might review documents, validate forms, screen content, or check if certain rules are being followed. It is not a general chatbot, but a focused assistant that performs a specific control task.

To judge whether you can trust such an agent, it is useful to compare it against realistic options. In many organizations, the alternatives are not ideal. Often you have a poor-quality manual control: people who are busy, under time pressure, skimming instead of reading properly, and making inconsistent decisions. Even if the intention is good, the actual quality of the control can be weak and unpredictable.

Another common alternative is a simple rule-based control. These are systems with rigid if/then rules or keyword lists. They are easy to understand, but usually brittle. They cannot handle nuance or context, they are easy to bypass with small changes in wording, and they can require a lot of maintenance to keep the rules up to date. They are also limited when the input is unstructured text.

In the worst case, the alternative is no control at all. This happens when there is too much volume, not enough time, or the process has simply grown without anyone designing proper checks. Then there is no systematic review, no consistent controls, and very little understanding of what actually slips through.

Seen in this light, the question “Can you trust a control agent?” becomes more concrete. You are really asking: is this control agent at least as good as a weak manual control, a simple rule-based control, or no control at all? If the answer is yes, then you might decide that you can trust the agent enough, or that it is better than the alternative.

This does not mean you should accept whatever the agent does without thinking. You can start with a small, limited use case and compare the agent’s performance to what you have today. Let the agent do the control in parallel with your existing manual or rule-based checks for a while. Look at what it catches, what it misses, and how consistent it is. In higher-risk situations, you can keep humans in the loop so that the agent helps with the routine checks, and people handle the difficult or uncertain cases.

You can also build trust by adding simple guardrails around the agent’s use. Log what it checks and what decisions it makes, so you can go back and see why something was approved or rejected. Let it signal when it is uncertain, instead of forcing a confident answer. Sample its decisions regularly and compare them with a human review, then use that feedback to improve how you use the agent.

In the end, trusting a control agent is not about believing it will never make mistakes. It is about comparing it to the realistic alternatives: a poor manual control, a weak rule-based control, or no control at all. If the agent is clearly better than these options, and you use it in a way that allows for oversight and correction, then it can be reasonable to say that you trust it enough for the job.

Language model–powered agents are starting to do real work: send emails, update systems, move data, trigger workflows. To be useful, they often need to act on behalf of a human: “send this as me”, “update my records”, “create a ticket from my account”, “book something using my company profile”.

This is relatively simple when the user is present and logged in. The real challenge is situations, apps and systems where the user is not logged in themselves, or not actively involved. The agent still needs the ability and the right to do things for the user, even when the user is away.

So the core question is: how do you give an agent the ability and the right to act on behalf of a human, without handing over your entire digital identity?

Today, the practical answer is often to share secrets. That might mean sharing an API key, sharing a password, or issuing long-lived refresh tokens that never really expire. These are used so the agent can log in to systems “as” the user, or as a shared technical user, and perform actions in their place.

These approaches are convenient and easy to implement, but they come with a lot of risk. One leaked API key or password can give access to everything that identity can reach. Long-lived refresh tokens become permanent backdoors into systems. Secrets spread into config files, logs and chat messages. It becomes hard to know who actually did something: was it the human, the agent, or someone misusing the same credentials?

There is also an operational problem: it is difficult to rotate these shared secrets without breaking many things at once, and access is rarely fine-grained. If you share a password or a broad API key, the agent basically gets “all or nothing” access. That does not match how we would like to think about trust, responsibility and control.

This shows that we need better ways to handle identity, access and delegation for agents. Instead of asking “how do I share my password with the agent?”, we should ask “how do I delegate a specific, limited set of actions to this agent, on my behalf, in a safe way?”.

A better approach would treat the agent as having its own identity, separate from the human. Access should be limited to what the agent actually needs to do: which systems, which resources, and which operations. Delegation should be explicit: the human grants the agent permission to act on their behalf, with clear limits and an expiry time. It should be easy to revoke this delegation later. And there should be good audit logs that show which agent did what, on behalf of which user.

Some of the building blocks already exist in identity and access systems: scoped tokens instead of long-lived refresh tokens, service identities for non-human actors, policy engines that can express what an agent is allowed to do. The missing piece is often using these tools to model agents and delegation properly, instead of falling back to shared secrets.

If we want agents to safely act on behalf of humans, especially in serious systems, we need to move away from sharing API keys, passwords and long-lived refresh tokens. We need better ways to handle identity, access and delegation that reflect what is really happening: a human asking an agent to act for them, under clear and limited conditions.

(Including Language Models and Agents)

We often say we want things to be cheaper: services, tools, housing, food. But if we look at how actors, agents, and processes are actually rewarded in our economic systems, there is very little real incentive for anything to become cheaper. In many cases, the system as a whole rewards higher prices and higher costs.

Who has an interest in low prices? An actor is interested in lower prices when they are buying something. As a customer, you benefit directly from cheaper goods and services. But the same actor has the opposite interest when they are selling, producing, or delivering something. Then higher prices and higher margins are better. This seems illogical at first, because you might think everyone would be interested in lower costs and prices in general. In reality, the interest flips depending on whether you are buyer or seller.

This is reinforced by how incentives, rewards, pricing models, and sales models are designed. They usually give better returns when prices and costs go up, not when they go down. The system as a whole now rewards increased cost. When prices rise, the value of property, assets, shares, currency – almost everything – goes up on paper. That looks good in portfolios, balance sheets, and valuations. It also means nobody is really rewarded for making things cheaper. Lower prices can be a threat, because they can reduce the measured value of what people and institutions already own.

The same dynamic hits agents and the language model industry, maybe even harder than some other areas. There is a lot of investment involved in building and running these systems: infrastructure, research, engineering, integration. When so much money is invested, there is pressure to sell services at a high price to “justify” the investment. In principle, you could invest a lot and still sell cheaply. But it cannot really become a trend that prices and costs go down steadily. If that happened, it would signal that the earlier investments and high valuations were not necessary or were overestimated. So the industry tends to protect higher prices instead of embracing falling costs.

To keep all of this going, more and more debt is taken on. People, companies, and states borrow money, which helps drive prices up even more. Debt allows actors to pay higher prices for a while, and supports rising valuations of assets and services. Over time, prices rise to the point where fewer and fewer can afford what they need. Housing, services, tools, and advanced systems become too expensive. At some point, the debt and the high price levels cannot be supported anymore, and the whole structure risks collapsing.

This logic affects how language models and agents are developed and offered. Technically, these systems could become cheaper and more accessible over time. But as long as incentives and rewards are tied to higher prices, higher valuations, and defending large investments, there is little reason for the industry to push costs down for everyone. The result is a system that does not naturally move toward “cheap and accessible,” but instead keeps moving toward “expensive and exclusive,” until almost nobody can afford it and the system breaks.