Making the Twin Forge Observable

How I connected a Hermes research workflow to Discord so I can follow its decisions and inspect the evidence behind them.

In my previous post, I introduced the Twin Forge, a small research team I built with Hermes to investigate uncertainty in cancer digital twins. The scientific goal is still demanding: establish a credible forecasting model, then test whether a sequential uncertainty layer can make its predictions more useful. Building agents that propose and run experiments was only part of the problem. I also needed to know what the workflow was doing while I was away from the terminal.

Giving each role a job

The first version had a Scientist and an Engineer. The Scientist chose the next experiment and interpreted the result. The Engineer implemented and ran it. That loop exposed a weakness: code completing successfully did not tell me whether the experiment followed its specification or whether the conclusion was justified.

I added a Verifier to check the implementation, artifacts, and data boundaries independently before the Scientist evaluates the result. An Advisor now checks in periodically and helps when the Scientist reaches an impasse. The Scientist still leads ordinary planning. The Advisor is there for guidance, not to prescribe every experiment.

The resulting loop has a deliberate order: the Scientist freezes a question and success criteria, the Engineer runs that experiment, the Verifier checks the evidence, and the Scientist decides what the verified result means. If the Scientist is stuck, the Advisor can help identify a different route. Each role has a purpose, and each handoff leaves a record.

The monitoring problem

An automated research loop can look active while making little progress. A long compute job might be running normally, an agent might be retrying an operational error, or the workflow might have stopped at a decision point. Those situations need different responses, but they are easy to confuse if the only view is a terminal transcript or a file that I have to remember to open.

We ran into concrete versions of that ambiguity. Questions about the provenance of pretrained weights stopped one proposed use of the segmentation model. A separate compatibility failure occurred before a model forward pass, so there was no scientific result to interpret. Other experiments reached an authorized cycle limit or a frozen scientific stop rule. From a distance, each case could look like “the agents stopped.” In reality, one called for evidence about the weights, another for a technical repair, and another for a research decision. I needed the workflow to tell me which situation I was looking at.

There is also a scientific distinction that a simple “done” message misses. An Engineer finishing a run means that outputs exist. A Verifier passing means that the run satisfies the frozen contract. A Scientist evaluating the result means that the evidence has been compared with the scientific criteria. A negative result can be valid and informative. A failed verification is an implementation or evidence problem. I want the monitoring system to preserve those differences.

Connecting Hermes to Discord

I connected the workflow to a dedicated Discord research channel. Hermes still runs the research roles, while a small notifier reads the workflow controller's recorded events and heartbeat. It reports when the Scientist, Engineer, Verifier, or Advisor starts and finishes a turn, when a turn fails, and when the workflow changes state or research route. During a long agent turn or compute wait, it also sends a periodic “still working” update. The diagram below is a guide to interpreting those updates in the next campaign.

This design keeps Discord as a window into the workflow rather than the source of truth. Experiment specifications, run manifests, metrics, verification reports, and evaluations remain in the research repository. Obsidian presents the learning record in a form I can read across experiments. The Discord channel gives me timely signals and experiment identifiers so I know which evidence to inspect. I can also ask the separate research bot for a current status summary drawn from those records.

The notifications are intentionally short. They do not copy full agent conversations, raw logs, credentials, or patient-level information into Discord. A notification outage also does not change the scientific state or stop an experiment; the notifier can retry from its last recorded position.

What I hope to learn from the stream

The most useful status update may be a handoff. It tells me who owns the next step and whether the workflow is moving through planning, execution, verification, and evaluation as intended. A sequence of repeated failures may reveal a dependency or compute problem. A verified negative result may tell me to stop tuning one model and test a different hypothesis. In either case, the short Discord message points back to the detailed record rather than pretending to be the analysis itself.

My aim is a more effective agentic flow, not merely a busier one. Clear status makes it possible to repair an operational problem without quietly changing the experiment, to ask the Advisor for a new direction when the Scientist is stuck, and to honor a scientific stop rule when the evidence does not support another run. It also makes my own interventions more focused. I can ask why an experiment stopped, what was independently verified, and what evidence would justify the next route.

The Discord connection and setup message have been tested. The automatic per-agent stream is wired to the next workflow run, so I have not yet treated it as evidence that a full campaign has been monitored end to end. That is the next operational check. The larger research question remains open, but the process for asking it is becoming easier to observe, audit, and improve.