Conor Svensson

How agents are making software provably secure

Mon, 22 Jun 2026 00:00:00 GMT

Software engineering in the traditional sense may be dead, but coding agents have created opportunities to bring rigour to software that was previously a pipe dream of engineers.

Agentic development has not only sped up traditional software development, providing engineering productivity gains of 20% to 50% depending on who you listen to, but also made development possible using techniques such as formal verification that historically were considered too slow or expensive to apply to a more mainstream engineering setting.

Formal verification extends far beyond traditional testing practices such as unit, integration, end-to-end and performance testing and instead achieves the holy grail of demonstrating robustness of software — that it is provably correct against a specification from a mathematical perspective.

Formal verification software has existed since the 1970s, and alongside functional programming, has remained a niche of software engineering, with many advocates of it due to the safety guarantees they provide. But adoption has been limited due to the steeper learning curves required for functional programming alongside the theoretical maths required for formal verification.

Developing applications with pure functional languages is very robust, but time consuming compared with the imperative approach favoured by most programmers.

Verifying code with formal methods adds another layer on top of this, making it a significant undertaking if used for non-mission critical infrastructure.

These barriers are now being challenged by LLMs. With the advent of agents taking on significant swaths of coding tasks, this doesn’t only apply to writing code, but testing and even proving it. Agents can now generate proofs to demonstrate the robustness of the code they are delivering.

This enables developers to see proof that code behaves as expected, which is far more significant than referring to generating tests or taking an agent’s word for it.

It’s also gaining traction in Web3, where there’s been hundreds of millions of dollars lost due to bugs in smart contract based applications. Pairing formal verification with smart contracts provides a level of resilience beyond what code audits alone can catch.

Getting Lean

There are a number of different software tools that can be used to assist with formal verification. Historically they were stand-alone tools for verification tasks, however, this has changed in recent years with the advent of Lean. Lean is both a proof assistant and functional programming language that has seen it gaining significant traction among mathematicians, researchers and developers.

Fields medalist Terence Tao, DeepMind and OpenAI are just some of the people and organisations embracing Lean to accelerate the field of maths which speaks to its influence.

To provide a simple example of the power of formal verification, imagine we have a function that transfers an amount of tokens from Alice to Bob. These can be defined in Lean as follows:

def transfer (alice bob amount : Nat) : Nat × Nat :=
  if amount ≤ alice then
    (alice - amount, bob + amount)
  else
    (alice, bob)

Normally tests for this code would be a series of statements verifying transfers are performed correctly.

#eval transfer 100 100 25
-- (75, 125)
#eval transfer 100 100 1000  -- invalid quantity provided
-- (100, 100)

However, instead of getting tests to be crafted, we could formally verify our function, to provide a guarantee that the total number of tokens held by Alice and Bob will never change following application of this function.

theorem transfer_preserves_supply
    (alice bob amount : Nat) :
    (transfer alice bob amount).fst +
    (transfer alice bob amount).snd =
    alice + bob := by
  by_cases h : amount ≤ alice
  · simp [transfer, h]
    omega
  · simp [transfer, h]

The proof is more complex to write than a test, but provides far stronger guarantees about the code, which is why getting agents to assist is valuable.

It’s important to keep in mind that this is a simple example to convey the essence of formal verification, but in reality these proofs are far more complex.

Securing Ethereum

Recognising the power of formal verification, Vitalik Buterin, creator of the Ethereum blockchain recently wrote about it on his personal blog.

There are a number of other initiatives happening in the Ethereum ecosystem using formal verification. Recently the Verity language emerged for writing smart contracts in Lean alongside a developer toolchain for it, Tama.

The Verifereum project is developing formal semantics of the Ethereum Virtual Machine (EVM) using the HOL4 theorem prover. The Vyper smart contract language is doing something similar with Vyper-HOL.

There’s even a prototype version of a zero-knowledge zkEVM being developed in Lean.

Formal verification elsewhere

Outside of Ethereum and web3, Jane Street are building a team to focus on formal methods as agents have made it financially feasible for them to do so.

There’s also a number of new AI companies focussed on improving mathematical infrastructure for AI, including Axiom and Logos Research.

With the explosion of coding agents, AI research and the need for more secure software, formal methods are having a resurgence which is unlikely to be short-lived.

The barriers to utilising them have dropped significantly, and as organisations become more dependent on agentic workflows, having confidence in the quality, reliability and safety of these systems will become ever more important.

However, in a similar vein to how coding agents don’t alleviate the need for programmers who still need to oversee their work, formally verified code is only as good as the specifications it’s being verified against. You still need experts who can verify the quality of the outputs.

We may be entering a new era of software engineering with formal verification being embraced. But without the right expertise onboard to monitor the quality of its work, you can still end up with slop, even if it has been formally verified.

From private chats to shared agents

Thu, 04 Jun 2026 00:00:00 GMT

Until this year, my time talking with LLMs had been via messages in ChatGPT or Claude. I’d used them for coding, but the results hadn’t been great.

I remember asking ChatGPT last year to scaffold code for an Ethereum Name Service CLI in Rust and the results were terrible — the code wouldn’t compile, poor dependencies were selected and I didn’t fancy throwing hours away getting it to work.

This changed with the new models that emerged at the tail end of 2025, which could write code reliably that would work.

However, throughout my own multi-year period of working with LLMs, my discussions had always been between me and my personal agent. There was no collaboration happening with them with a wider group — at best it was me exporting fragments of conversations to documents to share with others, but there was a lack of a collaborative process.

Why agents need to be shared

For agents to fulfil their potential, they need to work well in a collaborative setting and be shared. You can’t have teams going off and having their own individual conversations with personal agents and reporting back, they need to inhabit the same space as your colleagues and coworkers.

This missing collaborative tooling around shared agents is starting to be addressed, but it’s still far from mature.

For those utilising Microsoft, Copilot support has been available since late last year, whereby teams can work with a shared agent via a group chat, which can access resources aligned with the Teams workspace.

As with most Microsoft products, this is a configuration that works if you’re all in on Microsoft’s business offer and provides an integrated experience. Your agent also needs to be directed, due to context limitations it can’t be across the details of the latest updates to projects in your org workspace.

The reality is that most organisations have a number of different platforms and services which they rely upon, limiting the reach of Copilot which is bound to one ecosystem.

But this method of having agentic collaboration in group chats is something I expect to become commonplace for team collaboration.

Outside of the Microsoft ecosystem, this is being achieved by setting up agent frameworks such as OpenClaw and Hermes on their own dedicated servers, and then connecting them into messaging apps such as Slack or Discord where they can live as shared or personal agents.

If being used as a shared agent, they can be configured with access to project resources residing in shared collaboration spaces such as GitHub repos, Google Drives, email inboxes and calendars. Then team members can ask them to collaborate on work tasks whereby the whole team has visibility on the agent’s inputs and outputs.

They too can be set up as personal agents, where they are hooked up to WhatsApp or Telegram, with access to someone’s inbox and calendar and operate as a personal assistant to that person for private communication.

Both approaches provide all of the benefits of working with the frontier LLMs, but without having to go through the apps from those providers.

Flexibility has a cost

With the harnesses provided by OpenClaw and Hermes, models can easily be switched out, without having to regrant access to project resources as they are managed by the agent framework.

This reduces vendor lock-in, whilst retaining flexibility in this ever evolving space. But with this flexibility, comes responsibility for much of the plumbing underneath.

There is little doubt that these shared and personal agents will continue to proliferate, but there are challenges with using them. Hermes and OpenClaw need to be regularly updated. Their access tokens to the underlying model provider they use often need to be refreshed — I’ve had this happen three times in one of my Hermes deployments the past few weeks alone, leaving my agents unusable until I logged onto the associated server they were running on and fixed this.

When you start connecting these frameworks to external services such as Google Drive, Slack, WhatsApp and others, there are also credentials and permissions which need to be managed, which is where things can become brittle.

Even for a small organisation and my own needs, I’m setting up integrations with WhatsApp, Telegram, Discord, GitHub, Google Drive, Xero, Calendar and Gmail, all of which have the potential to need reauthentication at some point and close attention needs to be paid to access control.

For instance, whilst giving readonly access to an email account for an agent to use may seem harmless, it isn’t when you consider that multi factor authentication codes are often shared over email — are you comfortable with an agent being privy to this information?

Or if you’re giving limited access to write files to a specific directory in Google Drive — can you be certain that it couldn’t potentially access another directory if it was told of its identity by someone?

How about if you’re getting an agent to make code changes in GitHub — with the access control token you’ve given to the agent, does it have the ability to commit directly to a project repo, or are you certain it can only submit pull requests?

These examples demonstrate the challenges there are in provisioning agentic infrastructure correctly.

Shared coding agents

To reduce the complexity of these agent deployments, we’re seeing other agentic frameworks emerge which may better support specific use cases.

Claude Code and OpenAI’s Codex have been two of the leading CLI tools for agentic development. But their usage is limited to running in terminals or using their own apps.

OpenClaw and Hermes do provide a mechanism as outlined above for teams to collaborate on codebases, but it requires a lot of manual setup by teams.

Recognising these challenges, GitHub recently launched their Copilot app (currently in technical preview) which provides a shared collaboration space for teams to work on their GitHub codebases alongside Copilot agents.

The new GitHub Copilot app (source)

This will enable development teams to move beyond the singular conversations they have with coding agents and facilitate input from all members on what needs to be built.

If you want a more in depth breakdown, I recommend you check out Maggie Appleton’s post on it.

Paradigm and Tempo also recently made public their Centaur agent framework which provides secure coding agents over Slack.

Centaur has been designed for team collaboration with a significant emphasis on security, with credentials kept separate from the agents themselves and containers for conversations restricting the ability of the agents to cause havoc.

Whilst these are a couple of recent examples, it seems inevitable that we’ll see more agent frameworks launching that are built for specific types of work.

The frontier labs have been vocal about their focus on supporting developer workflows with their models, and now that developers are utilising agents to various degrees for their coding activities, it makes sense that the collaborations used by teams evolve to support this.

OpenClaw, Hermes and the others I’ve touched on are early to the party in providing the platforms that can be used to coordinate work among agents. We’re at a transitional point, but over the coming months these platforms will proliferate as teams adopt them, supporting the next phase of growth in agentic workflows.

Why non-engineers ship unmaintainable code with AI agents

Wed, 13 May 2026 00:00:00 GMT

Working with coding agents creates addictive feedback loops. The agent is optimised to craft a response, not push back on your questions. This creates an illusion of progress, where the agent is trying to appease you, rather than thinking critically about what you’ve asked it to do.

This is fine if you’re creating a personal project, or quickly throwing together a prototype, but inadequate if you’re trying to build a real product.

Being attuned to one’s environment is crucial. Providing adequate context for the task at hand helps the agent take its surroundings into account.

The challenge I see with many of the people embracing agentic engineering is that the context they bring is often limited to their own world-view or skillset.

People working with agents may have ideas of what they want an agent to build. But unless they understand software engineering, they are unlikely to be concerned with how it is built.

This is not a problem when building a simple prototype or personal tool. But if you’re trying to build something other people rely on such as a project, service or business, it’s unlikely to work in the way you envisioned.

The tight human-agent feedback loop can all too easily result in the appearance of rapid progress, with the agent being your own personal hype-man, making you feel good about what you’re building, when in fact people need to take a step back and reflect on what their agent is doing and if it is actually a good idea given their surroundings.

This ability to take a step back and question the bigger picture, sometimes referred to as metathinking, is a trait of human intelligence which machines have not developed. It matters especially when working with LLMs which are happy to endlessly work on a problem if their operator asks them to.

Machines take a brute-force approach to solving problems, and because LLMs are so good at this brute-force approach, it’s all too easy to chase the wrong solutions.

It’s no different from a developer wasting time working on the wrong feature for a product, because someone didn’t adequately describe what was needed.

The problem is this illusion of progress can magnify this and create unmaintainable codebases very quickly.

Even if someone is working on the right problem, they may lack the right intuition about the agent’s environment to guide it appropriately. If a person does not tell their agent to follow good engineering practices, such as separating concerns and delineating appropriately between components, they will end up with an increasingly chaotic code base, where their agent is optimising for operator happiness over a well structured environment.

I was recently reviewing a friend’s code they had put together to enhance an AI personal assistant on Hermes. Hermes is an AI personal assistant with persistent memory across conversations. They had something that worked, but it was tightly coupled to Hermes.

They had effectively created their own distribution of Hermes to solve their problem. On the surface this is reasonable, but there were two glaring issues I saw with this approach:

They would be responsible for updating their code every time there were any changes to the Hermes installation process.
It couldn’t target an existing Hermes installation.

I worked with my agent to examine the codebase properly, but the crucial thing that had been missing from my friend’s work had been asking his agent to ensure that his code followed clean architectural patterns.

A prompt as simple as the below would have prevented these issues.

“Integrate with Hermes as an external dependency, not as an embedded platform.”

Passing this prompt to their agent can subsequently fix the issue. However, it cannot guarantee that nothing breaks, and following a major architectural change to the codebase, significant amounts of testing will be required.

Herein lies one of the significant issues facing non-engineers building products with LLMs. Optimising for maintenance and stability is unlikely to be front of mind, but in order to provide a high-quality product for end-users, it cannot be overlooked.

When someone asks an LLM to add a feature or fix an issue, they are unlikely to be cognisant of the change happening behind the scenes.

An experienced engineer is able to bring a wider contextual understanding of the business or underlying technology into their decision-making. An LLM cannot do this without being asked.

Hence with the proliferation of products being summoned into existence via an LLM, the quality and reliability of these products is often poor.

This isn’t to detract from the ability of LLMs to create software — they can do a brilliant job, and my engineers use them for their coding. But without an operator who understands good engineering, what gets built isn’t a product, but a prototype that breaks as soon as anyone tries to change it.

What we learned trying to give an agent our whole company

Thu, 23 Apr 2026 00:00:00 GMT

Enscribe is being built by a remote-first team. Everything we do is recorded somewhere — we transcribe our video calls, chat via instant messaging, store our docs in Google Drive, host our code in GitHub. All of this should be useful context for an agent, but very little is.

We’d look at the various integrations such as Google Drive in ChatGPT, and whilst you could connect to your drive, you’d have to pull out specific documents to include them in a chat session and be hit with hard limits of 10 files for a single prompt.

We even optimised our code repos so that there was a single source for our product landing page, documentation and blogs, all conveniently stored in Markdown. Our thinking was that this would provide everything an LLM would need to know about the current state of the project.

Context windows

The limiting factor here was not our ability to surface useful information for the agents, it was the context window of these agents.

Context windows are the working memories that you have with an LLM. When you establish a new session with a generative AI chatbot such as ChatGPT or Claude the context will have minimal information in it, beyond the instructions that OpenAI or Anthropic have told it to load with.

When you start typing requests and adding files to the discussion, the history of your discussion and information about any shared files is summarised in the context window associated with your session.

Currently, the leading models use a context window size of one million tokens and whilst they will continue to grow, the volume of data they can keep in memory, remains orders of magnitude smaller than the size of the datasets these models are trained on which is internet scale.

In order to prime agents with useful information to serve specific requests, they are given skills files and instructions specific to projects. These documents are written in markdown with names such as SKILLS.md and AGENTS.md and give the agents the information they need to be more helpful to the people they’re speaking with.

For instance, Claude provides a Powerpoint skill which is a file describing how to create compelling slide decks.

Whilst in the Claude app, skills such as this are dressed up as software plugins, they’re a text file behind the scenes.

This is because LLMs thrive on text. Hence if you want to train an agent about your organisation you want to feed it text.

Skills and agent files alone aren’t enough for this, they teach agents how to do things. They can’t teach agents about your organisation, as they lack the data about it.

The answer isn’t increasing context windows, it’s converting your organisational knowledge into archives that the agents can explore on demand.

What we built

We started thinking about how best to train our own agents with richer information about our organisation.

We already had data being recorded about what the team was building, but we needed to find a way to consolidate this into an easily digestible format for LLMs.

We wanted to have data repositories that can then be passed to an agent, much like a code repo is, and the agent can explore them like it does a codebase.

Instead of leaving our data spread across multiple sources, we’ve started consolidating data into a number of different LLM-friendly formats, which makes it far easier to provide context when required about what’s happening.

Our code related assets remain in GitHub. However, we want to ensure that we’re regularly updating our blog and documentation pages with new features and changes as we make them.

With Claude Code and OpenAI’s Codex, LLMs are already adept at working with these source formats, and while we don’t need to do additional work once they’re in these repos, we’ve consciously made the decision to try and keep as much information in one place instead of spread across lots of separate repositories.

All our video calls are being transcribed and summarised. We set up daily jobs that create markdown versions of these files and stores them in project specific folders. Likewise our instant messaging discussions are being exported in markdown to folders.

These folders are then being indexed for agents by having AGENTS.md files in their root, with index files that break down how the individual files are organised hierarchically.

For instance, with Enscribe we have a knowledge base folder containing directories for our meeting notes and chat. In this location we have markdown archives of our discussions organised by date.

knowledge-base/
  meeting-notes/
    2026/04-April/2026-04-07-Team-sync-2026-04-07-11-30-BST.md
    ...
  text-chat/discord/team/
    2026/2026-01-27.md
    ...
  INDEX.md
  AGENTS.md

These are supplemented with:

an INDEX.md file which lists the number of files by month, year and type as well as the most recent files
an AGENTS.md file outlining the retrieval protocol to use

This same pattern is then being extended to other tools such as collaboration tools and those parts of the organisation such as our finance systems where there’s useful data being generated.

Now when someone wants to know what we decided last week regarding the latest feature for Enscribe, the agent can answer for us. Before, this would have required searching through meeting notes or chat histories.

Working memory will likely remain a constraint in the foreseeable future, but by ensuring we have high quality data archives in text-native archives, we have the right foundations to share topical information with agents when we need to.

Agents may not yet be able to store all of this in working memory, but we can be confident that as their capabilities increase we’ll be able to take advantage of them quickly, without being constrained by a specific vendor platform.

The agents will get better, and the data archives you build now will still be useful when they do, but the inverse is not true.