This is the next instalment in both the StyloAgent and GEPA article series. It continues The StyloAgent Workflow, Part 2 and Evolving Decision Policies with GEPA and Decision Models, bringing persistent agent coordination and evaluated policy evolution together.
Getting agents to work in parallel creates a coordination problem. When one agent says a change is ready, the others need to know which state that claim applies to. A reviewer, a capture agent and a deployment agent can all be doing reasonable work while talking about different revisions.
That problem showed up between agents working on StyloBot. The fleet developed a convention of explicitly pinning the current state, and the convention is now used in StyloMail to support parallel work.
The overview agent originated the way of communicating state through compact references to the shared bus. I subsequently updated StyloAgent to surface useful conventions for other fleets. The sequence is what interests me: an agent encounters a coordination problem, develops a working practice, and that practice becomes useful elsewhere.
In the previous article, I explored using GEPA to evolve decision policies through evaluated changes to their instructions. This follows that idea into communication. The speculation is how far these existing adaptations could go: could practices shared between agents develop into a richer language of operations?
StyloAgent gives specialists persistent ownership, their own worktrees and saved context, and a message bus through which they coordinate. The second article shows how those conversations preserve decisions and their provenance.
Here is a real message from the fleet:
From: overview-
Timestamp: 2026-10-19T12:22:17.5540280+01:00
Priority: urgent
desktop-combined-capture-go-b23535e
Review GO on exact b23535e: Host 713, Queue 138, Persistence 20; direction-first plans, mask extraction, no raw address, own mailbox excluded, cross-tenant controls. Main is b23535e.
CAPTURE GO: one combined run at 1180x720 for (1) the corrected dashboard with attention split and Service notes, and (2) the masked recipient list row. Report paths, hashes, Host build id and the exact visible labels. If a state is unproducible, name it
That is recognisable English, with a lot of operational shorthand. It pins a revision, specifies an operation and its parameters, lists constraints, and asks for evidence. It also specifies what to do when the requested state cannot be produced: say so.
Compared with “take some screenshots”, it carries a substantial working contract: which state, which views, which constraints and which proof. The state pin gives parallel work an explicit reference point. Other agents can coordinate their own work against that state instead of assuming that “current” means the same thing to everyone.
I watch the fleet develop workarounds for problems the agents encounter, then share them. They carry lessons from earlier work into later instructions and coordination. The result is accumulated working practice, expressed through the messages they send each other.
There is a further question hiding in that message, though. An outside reader lacks the context for references such as Host 713, Queue 138 and Persistence 20. How does an agent recover the meaning behind shorthand without carrying the entire working history in its context?
This is a mixed-model fleet. Agents run through Codex, Claude and OpenCode, with DeepSeek models communicating with Sol among the combinations in use. Those agent environments and models bring different contexts and behaviour to the conversation. The working conventions are already being used across those differences.
MCP gives them a stable interface to the shared message bus. They send and receive messages through defined tools, while the bus retains the conversation. The overview agent developed its convention using that existing interface.
A compact reference can point to another message containing a finding, an agreed workaround or the evidence behind a decision. An agent can recover the detail from the bus instead of needing everything in its own context window. The message can be smaller than the knowledge it invokes because the rest is available through a shared interface.
That is an important part of this system's shape. MCP supplies the stable access mechanism. The bus supplies working history. The agents develop conventions for what to say, what to refer to and how to use what they find. A DeepSeek-backed agent and a Sol-backed agent can coordinate around the same pinned state and refer back to the same messages.
This connects to the distinction between MCP and architecture. The interface gives the agents mechanics they can rely on as their working practices develop. It also gives us somewhere to anchor more explicit definitions if those practices become reusable procedures.
In Star Trek's Darmok, references such as “Darmok and Jalad at Tanagra” and “Shaka, when the walls fell” invoke shared stories. The words depend on background knowledge the listener must possess. The official Star Trek discussion explains those references.
Software teams do something similar. “Roll it back” can invoke a procedure involving an artefact, an environment, compatibility checks and verification. The phrase is much smaller than the procedure.
Different models may have overlapping prior knowledge that makes familiar references useful. “Two-phase commit” can suggest a known pattern, but the participants and exact implementation still need defining. For a local incident, the bus can provide the shared story. A receiver can follow a reference to the exchange where the problem and workaround were recorded.
There are several sources of meaning here:
| Mechanism | Where the meaning comes from |
|---|---|
| Familiar technical reference | Prior knowledge, which may differ between models |
| Local shorthand | A convention communicated through interaction or saved context |
| Shared bus reference | An earlier message the receiver can retrieve |
| Versioned operation reference | An explicit definition the receiver can inspect |
That last row is the possible next step. A history tells us what happened and what the agents did about it. A reusable definition could capture when to apply the resulting procedure, which inputs it needs and what should happen when it fails.
The September 2026 GlossoGen preprint explores language emergence in a purpose-built environment, including the effects of communication pressure and opportunities to negotiate, and whether newcomers can learn the resulting conventions. Transmission varies with the conditions. For this proposal, that makes inheritance a useful question to test: how much of a practice can another agent recover from its recorded meaning?
This brings us back to DiSE, Directed Synthetic Evolution: generate alternatives, evaluate them, retain useful variants and improve them through feedback. Generated work becomes an artefact with a lifecycle, carrying something useful beyond an individual model response.
The GEPA paper supplies a concrete method for reflective prompt optimisation. It uses execution feedback to propose changes and evaluate candidates, preserving complementary candidates during search. My previous article explored applying that machinery to versioned decision criteria.
Here, the candidate artefacts would be coordination conventions. The fleet already originates and shares them; GEPA offers machinery for investigating how to refine them systematically.
For capture-and-review work, for example, we could compare variants requiring the request to name the reviewed revision and the response to identify the revision actually captured. Test them on tasks where stale state is a possibility. Retain variants that reduce mismatches; revise or reject ones that create confusion or excessive rework.
That is the spiritual succession: reusable tools in DiSE, decision policies in the GEPA proposal, and now the possible evolution of a working language. Its vocabulary would grow from operations the agents perform and problems they encounter.
Reflexion supplies an earlier connection through reflective text in external memory affecting subsequent trials without weight updates. When LLMs Develop Languages, published at ICML 2026, studies constructing and selecting compact symbolic protocols for reasoning. These connect to different parts of the proposal: retaining feedback, defining shared operations and reusing those definitions.
Suppose we gave reusable conventions explicit definitions in a shared, versioned manual. The fleet could propose changes, evaluate them on coordination tasks and adopt useful revisions. A compact invocation would then have a definition that stands on its own, alongside the bus history that explains how it developed.
Return to the capture message. Its operation could define:
| Part | Question it answers |
|---|---|
| Operation and version | Which procedure is being invoked? |
| Preconditions | Which revision and application state must exist? |
| Inputs | Which views and capture dimensions are required? |
| Constraints | Which data must be masked or excluded? |
| Evidence | Which artefacts, hashes and build identity must be reported? |
| Failure response | What happens if a requested state cannot be produced? |
An illustrative invocation might look like this:
# Proposed syntax; not an existing StyloAgent command.
operation: capture_reviewed_ui
definition: fleet-manual/capture_reviewed_ui@1
reviewed_revision: b23535e
viewport: { width: 1180, height: 720 }
views:
- dashboard_attention_and_service_notes
- masked_recipient_list_row
These operation and view names are invented for the example. Their definitions would carry the constraints, evidence requirements and failure behaviour. The definition reference would resolve to immutable content, with dependencies pinned too. An unavailable definition should produce an explicit unknown-operation response.
There are three layers: the message invokes work, the manual defines the procedure, and the runtime controls permitted actions and verifies what it can. A hash identifies the retrieved definition; acceptance tests check whether an agent can use it correctly, including on stale revisions and unmasked views.
If a procedure becomes stable enough, parts of it could become code. A tool can check the revision, validate fields and reject missing evidence. Other parts may remain semantic: checking screenshot dimensions is different from deciding whether the image communicates the requested state. Every compact invocation should also expand into something a human can inspect.
The boundary from the GEPA article still applies. The manual can evolve while permissions and independently specified acceptance conditions remain outside its control. A revised procedure cannot grant access to another tenant's data or redefine an incomplete capture as success.
There is prior work on deliberately designed prompt languages, including LMQL's Prompting Is Programming. The question here is whether operating experience could help agents develop and refine the coordination definitions themselves.
I would start with repeated capture-and-review tasks, using fixed model versions, tools and independently checked outcomes. Compare existing conventions with candidate revisions on matched tasks, reserving held-out cases the revisions have never seen. Keep the evaluator, permissions and acceptance conditions fixed.
Compare the ways of conveying meaning from earlier: familiar technical prose, local shorthand supplied with its negotiation history, references to earlier bus messages and references to a versioned manual. Include continuing and fresh agents, both from the same model and another model family. Unfamiliar combinations of familiar requirements would help distinguish composition from replay.
Measure verified completion, stale-revision work, unsupported completion claims, clarification and retry counts, and total cost per accepted outcome. Include negotiation, retrieval, review and rework. Count tokens using each model's actual tokenisation: fewer visible characters do not guarantee fewer tokens.
For the manual condition, remove conversational history. Supply an unknown operation or an unavailable definition and check whether the receiver asks for the missing meaning. If a fresh agent can retrieve a definition and use it on held-out tasks, we have evidence that useful adaptation resides in a transferable artefact. We can then investigate which practices generalise and which need local context.
Current-state pinning has already travelled from coordination problems in StyloBot to parallel work in StyloMail. Different models already participate in those working practices, and StyloAgent now has support for surfacing useful conventions for other fleets.
That is the starting point for the speculation. A richer working language could make those practices easier to retrieve, combine and adapt. A receiving fleet might inherit both a procedure and the recorded experience explaining why it exists, then refine it for its own work.
The interesting experiment is whether that process can become cumulative: useful conventions develop through operation, travel between fleets and remain open to evaluation and improvement. That would carry the DiSE and GEPA thread into the coordination layer itself.
The model does not have to change for the system to learn a better way to work.
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.