DEV Community: Panu Horsmalahti

Time is ripe for the A2A software factory

Panu Horsmalahti — Sat, 07 Nov 2026 10:32:37 +0000

The time is finally ripe for multi-agent systems, e.g. agent-to-agent (A2A). This has been the hype for the past year, but finally the pieces are coming together to make it useful. I don't mean the simplistic use of subagents in Claude or simply having different roles using prompts.

I mean creating multiple autonomous / independent agents with their own identity, memory, permissions and workspaces. To make this work in a secure way you first of all need a proper "governance" system, e.g. agent sandboxes which allows different agents having different policies and their own computers. Our own product here is Lens Agents by Mirantis.

Then, you need a "harness" that is designed to be autonomous, which includes a memory and identity system, not a simple "you are role x" prompt. Think of basically what OpenClaw was doing, but nowadays there are better options from most players in the space (at Lens we have our own Prism agent, of course).

The actual protocol of doing the communication between agents doesn't really matter. It can even be done through Slack - or through a custom implementation. These enterprise "open" standards like A2A are not really important here (and who even uses those?). Implementations are cheap which makes protocols less useful.

The whole multi-agent platform should also be running remotely, not on developer machines. It should also be "multiplayer", e.g. multiple humans should be able to interact with these agents. The point is not creating an army of agents running on your laptop.

If you have all that up and running you are ready to create a state of the art software factory.

LLMs create insecure software as of today

Panu Horsmalahti — Thu, 29 Oct 2026 10:34:06 +0000

LLMs have a bit of a general issue, which is that they don't produce correct, high-quality code in one-shot. The solution is to have other LLMs review the code in a feedback loop to resolve the issues. Only after that can you have some confidence that the output is correct or good enough.

Why is this a problem?

Well, the problem is that LLMs don't produce secure code in one-shot either. The solution to have other LLMs review the code for security defects. Unfortunately, this is problematic, because to get high security you really need adversarial security review, but that is blocked by frontier AI companies.

The AI companies correctly reason that if you can do proper security reviews against the code you've produced, you can also use that capability against code (or systems) that you don't own, which would allow users to carry out cybersecurity attacks. There is no easy way around this. AI companies can't reliably detect if the code was "originally created" by their own AI, because there would be many ways around such detection.

You can, of course, try to apply for elevated access, but the vast majority of developers using AI can't or won't do that, which means that this is not an option for the vast majority of developers.

Another practical workaround is using open-weight Chinese models that don't have such a restriction. However, Chinese models might start to have such a "block" too, as K3.1 Pro's open-weight version, for example, lacks cybersecurity data. And many companies don't allow the use of Chinese or other open-weight models.

We can't solve the security issues with human review either. The vulnerabilities that LLMs will produce are not trivial issues but something that almost no human can spot. However, any attacker who has access to a frontier model (without cybersecurity restrictions) can easily reveal them.

It seems that we have hit a roadblock for security. Could there be a way to ensure high security for software but not allow attackers to break other systems?

My solution is as follows: AI providers can host the software in a feature called "secure cloud". Companies will submit their packages to the AI company, which does the adversarial security review and patching themselves in a "black box", never revealing the vulnerabilities. The AI providers then offer a standard cloud hosting service and don't let the customer access the patched version of software. This, of course, would be incredibly profitable for the AI companies.

Agent user interfaces should be based on DOM, not chat

Panu Horsmalahti — Fri, 02 Oct 2026 13:20:19 +0000

Essentially all interfaces to agents are copies of each other: display some kind of history of chat/text messages. The issue with this is that it's based on "history", even though by default users don't need to scroll up and down the history, but instead want to receive the information and move on. The "chat" concept has been expanded by adding images and other rich media, even small "Apps" to the chat history.

The natural evolution of this interface is leaving out the history and simply letting the agent control what information should be visualized for the user, and in what form. We can easily use DOM for this simply because agents are really good at using that interface. The agent can invent ad-hoc components required for the visualization. The exact technical solution, however, is not that important.

I made a prototype for such an interface and it looks like this:

The user can talk with the agent using voice chat and natural language, and at any given time the agent can choose to show whatever is requested by the user. After the user has seen the information, the screen can be "cleared".

If we try to look even more to the future, computing will likely evolve into a "one app" concept, where you only have one interface and one app to talk with the agent, and the agent will do whatever is the task. This will of course require us to think through use cases from the "first principles" instead of trying to force existing apps into this agentic UI.

Will software ever be free?

Panu Horsmalahti — Tue, 01 Sep 2026 05:55:43 +0000

Lets assume that in the near future the following will be true:

Coding agents are better than 99% of software engineers
Tokens are practically free

If and when we get there, will software be "solved"? Will code become free to produce at a high quality? My answer is.. not quite, and the reason is data.

I don't just mean "big data", the data that large companies utilise to steer their services. I also mean "small data". Small data are the large number of small decision one has to make when creating software. This is called the "spec".

LLMs can of course make these decisions. And once models get better, they ought to get better at it. However, I don't think training data will include all the possible decisions for all software. Some spec will remain essentially proprietary. This means humans will have to make the choices, and this will take time and effort.

This time and effort will therefore impose a lower bound for the price of software. Companies will of course find the right answers over time, but the price of software will remain non-free.