/digitaldrive/images/Digital_Drive_logo.png){kind=logo}
Digital Drive
IT Solutions
The Night I Stopped Being the Messenger
For a while, using more than one AI assistant has meant doing a lot of work between the work: ask one model to change something, copy the results to another model for review, bring the review back, explain what changed, and repeat. The models can be useful, but the person at the keyboard becomes the courier.
Tonight, I took a practical step toward changing that.
I set up a small, controlled engineering environment where one AI coding agent can implement a task and another can independently review the actual changes. The reviewer returns its findings directly to the workflow. The tests, differences, review reports, and commit evidence are saved alongside the project. I can watch the process, inspect the evidence, and decide what gets committed—without manually carrying every message between the two systems.
It sounds simple. Making it reliable is the engineering.
I didn't give the agents unrestricted access to my computer. I designed the development environment with deliberate security boundaries. The agents receive only the access and reference material needed for their assigned work. That lets them collaborate effectively without granting unrestricted access to my working environment.
I also gave both agents the same foundation: my working philosophy, an explanation of how I approach problems, and the project's architecture and current decisions. The instructions tell them to work from evidence, expose uncertainty, question assumptions, and report conflicts rather than quietly papering them over.
That is not just housekeeping. It is part of the system design. An agent should have enough context to do useful work, but no more access than its role requires.
The first real test was a persistence task in a project I'm building to preserve the reasoning and evidence behind cybersecurity consulting work.
An engagement needs to survive more than the current program run. If I stop work and return later, the system should preserve the investigation's history and the evidence behind its conclusions.
We added persistence capabilities and safeguards designed to protect the integrity and separation of engagement data. We then tested both normal operation and failure cases to check that the protections actually worked, rather than simply assuming the code was correct.
The important part wasn't just getting the tests to pass. We also used controlled tests to demonstrate that the safeguards were necessary. That gave us evidence that the design was doing meaningful work.
The implementation agent ran the tests and packaged the real code changes, test output, and a concise explanation. It then invoked the second agent in read-only mode to examine the changes independently.
The reviewer found issues the implementation agent had to consider. One example was a test that claimed to verify more than it actually checked. We corrected the discrepancy rather than letting the documentation overstate what had been proven.
Another review identified a data-integrity edge case that needed further attention. We recorded it as a follow-up task rather than allowing the issue to disappear once the immediate work was complete.
The agents do not get the final say. Two models agreeing is not proof. Their recommendations still have to match the code, the tests, and the intended architecture. I decide what is in scope and when a change is committed.
But they can now exchange the actual artifacts directly. I no longer have to copy a diff into another chat, ferry a review back, and manually reconcile every comment. Independent review is now integrated into the workflow, with saved evidence and human approval.
That's the moment it started to feel less like juggling chat windows and more like refereeing a technical match: one agent serves a change, the other challenges it, the first responds with evidence, and I make the call.
Each change is deliberately small. The work is divided into commits with clear messages, and the evidence package records the changed files, tests, review findings, commit identity, and final repository state. The repository was clean after the latest commit.
The final validation runs passed, and controlled checks showed that the safeguards were doing their intended work.
I see a clear path forward for this project. The prototype still needs further validation, but we now have a repeatable process for improving it without sacrificing scrutiny or control.
There are limitations to tackle, not reasons to pretend the progress isn't real.
The value here is not that an AI can type Python quickly. The value is that I am turning an engineering method into a repeatable process: define the boundary, make one change, test it, have a second agent challenge it, preserve the evidence, and only then commit.
The same discipline matters in cybersecurity consulting. A fluent answer is not enough. I need to know what was observed, what was assumed, what was tested, what the evidence supports, and what remains uncertain. The system should make those relationships inspectable, not hide them behind a confident-sounding conclusion.
This is an early prototype, not a finished autonomous engineering platform. It still needs human direction, approval, and judgment. But tonight, two agents worked through a real code task and an independent review with less manual coordination, under explicit access boundaries, with a reproducible evidence trail.
That feels like a meaningful step toward the kind of work I want to do: using AI to extend human capability, while keeping responsibility and the final decisions in human hands.
The next milestone isn't to add a dozen agents. It's to keep this small loop trustworthy, resolve the next integrity gap, and automate only what we've already shown works.
The real achievement wasn't getting an AI to write code. It was building a controlled process in which AI-generated work can be challenged, tested, traced, and improved.
Digital Drive IT Solutions
Demystifying technology so people can make better decisions.