Part Two: The Mesh Finally Ships

A data product and an agent's work order have a problem in common. Someone has to use them without carrying the producer's knowledge around in their head. Data mesh gives us a useful way to design that handoff, and agent systems give us a reason to take its maintenance requirements seriously.

Consider an illustrative engineering task. A worker receives an issue asking it to update a report. The issue names a dataset, but leaves out what a status field means, which version of the schema applies, and who can approve the result. A colleague who built the report might explain all of that. A replacement worker receives only what the system has made available to it.

The missing explanation becomes part of the job. The worker has to find it, ask for it, stop, or make an assumption. An agent can make the assumption sound perfectly reasonable. The report can look finished while answering a different question from the one its owner intended.

That risk is familiar to data engineers. A table can have a name, a location and valid rows while still being unusable to someone outside the team that created it. The work required to make it usable includes documentation, ownership, access rules, quality checks and a way to handle changes. Those are recurring obligations. Creating the table pays for none of them automatically.

The original appeal of data mesh was that domain teams could own and serve useful data without routing every decision through a central data department. That arrangement depends on each product carrying enough information for another team to consume it. A consumer shouldn't need a private tour of the producer's business before every query.

Agent workflows put a similar demand on issues, specifications, tool descriptions and results. A worker may start with no memory of the preceding conversation. Its permissions may prevent it from opening the system that supplied an input. Its assignment may end before a downstream consumer begins. Context has to travel through a maintained record.

An agent harness is the software that gives workers their instructions, tools and execution environment, then records and checks their work. A well-designed harness can make those handoffs explicit and enforce parts of them with code. That creates a useful convergence with data mesh. Domain ownership, usable products, shared infrastructure and executable governance all have counterparts in an agent workflow.

The convergence is conditional. Adding agents to a queue doesn't establish any of those properties. A poorly maintained specification can mislead a whole fleet, and an automated check can enforce the wrong rule more consistently than a person ever could.

The practical question is which recurring obligations the system makes cheaper to satisfy, and which ones it merely assumes someone will remember. That question takes us back to what data mesh asks its owners to provide.

Zhamak Dehghani's data-mesh work puts domain knowledge close to the people responsible for serving the data. A central team can provide excellent infrastructure and still become a bottleneck when every question about meaning has to pass through it. The team that understands a business event needs a role in explaining what its records mean.

That diagnosis leads to four principles. Each answers a different part of the handoff problem, and leaving one out puts extra work on the others.

Domain-oriented ownership puts responsibility with the team closest to the business activity. A domain team publishes its data and answers for its meaning, quality and changes. A central platform team can still operate shared services. Ownership concerns the product and its obligations, rather than who personally maintains every server.

Data as a product adds the consumer's side of that responsibility. A collection of tables becomes useful beyond its originating team when another team can find it, obtain authorized access, understand it and judge whether it fits a decision. DATSIS is a mnemonic for those product properties. The six questions below make the properties concrete.

A product can pass one question and fail another. A dataset may be easy to find but impossible to interpret. It may have a stable endpoint that returns data whose freshness is unknown. It may be well documented and expose records its consumer has no right to see. The properties describe different obligations, so a catalog entry alone can't stand in for the whole product.

The self-serve platform gives domain teams a supported way to publish and consume products. Teams need common capabilities such as access controls, schema handling, discovery and delivery. Requiring each domain to invent those capabilities would turn ownership into a second infrastructure job.

The platform therefore changes the practical cost of taking responsibility. A team can focus on the meaning and usefulness of its product while using shared machinery for repeatable operations. Calling a domain autonomous while making it file a central ticket for every change leaves much of the old bottleneck intact.

Federated computational governance supplies the common rules. Domain owners help determine standards that apply across products, and software enforces the parts that can be checked. A compatibility rule can reject a change that would break an agreed interface. An access policy can refuse an unauthorized request. People still decide what the policies should be and how exceptions work.

Computational governance puts a check in the path where a violation can occur. A policy document may explain a rule. The execution path needs a way to apply it.

The compiler connection begins at those shared boundaries. A common representation can reduce bespoke translations between producers and consumers. It still needs agreed meanings and supported changes. A connector that accepts the shape of a record hasn't established that both sides understand the record the same way.

That's the work the four principles distribute. Domain teams own meaning and product commitments. A platform supplies shared capabilities. Cross-domain governance protects the agreements that let products compose. Each part creates maintenance somebody has to keep doing after the launch presentation.

A mesh can retain the language of the four principles while losing the operations that make them work. The failure is easiest to see by following what happens after a product changes. Somebody adds a field, changes a business definition, replaces a source or retires an endpoint. Every consumer now depends on the producer keeping its promises through that change.

Documentation, contracts, quality checks and discovery all need attention as the system evolves. A project budget can pay to create them once. A functioning product needs a way to maintain them.

A team can rename a table as a data product without assigning anyone to investigate a consumer's problem. The catalog may describe the launch version while the live dataset follows a different schema. The table still exists, the entry still looks complete, and the consumer pays for reconstructing what changed.

Product ownership has failed at that handoff. A maintained product needs someone who can answer for it, evidence of its current condition, and a supported process for changing or retiring it. The cost includes talking to consumers. Some important defects concern meaning and fitness for use, which a schema checker won't discover on its own.

Governance can lose its computational part in a similar way. A group agrees that breaking changes require a new version, but the publishing path accepts any schema. Someone has to notice the violation during review or after a consumer breaks. The rule exists as a statement of intent while the system continues to permit the forbidden change.

A meeting can be the right place to resolve a disagreement about a policy. A repeatable compatibility decision belongs in a check once its terms are agreed. The two activities have different jobs, and each needs an owner.

A domain team also needs the capacity to fulfill its assignment. Declaring that the team owns a product doesn't supply engineering time, operational support or a way to grant consumer access. A platform that leaves those tasks unsupported can send the work back to the central team, even while an organization chart shows distributed ownership.

Conway's law describes a constraint behind that mismatch. The communication and decision paths available to the people building a system constrain what they can sustain. An architecture diagram doesn't remove those constraints. Teams need authority and resources that match the responsibilities the diagram assigns.

These mechanisms can reinforce each other. A domain waits for platform support, its documentation falls behind, consumers seek help from a central specialist, and that specialist becomes the route through which subsequent changes pass. The old dependency can reappear inside the new terminology.

The maintenance burden resembles a gym membership in one useful respect: buying access and sustaining a practice are different commitments. The comparison stops there. People and organizations can sustain demanding practices; the design question is how those practices are funded, rewarded and supported.

Treat these as failure modes to inspect, rather than a verdict that data mesh failed everywhere. Ask who updates a product's description when its schema changes, which check catches an incompatible release, and who repairs the check when it stops running. An answer that depends on someone remembering describes an unresolved maintenance obligation.

Streaming adds another set of obligations to that same arrangement. It can improve the handoff, but it also changes what keeping the product usable requires.

A batch product can deliver a table at an agreed interval. A streaming product can deliver events as they occur or maintain a view as new events arrive. The consumer's question changes with that choice. It needs to understand what happened, which changes are available, and what guarantees apply while the flow continues.

Hubert Dulay and Stephen Mooney develop the streaming version of this approach in Streaming Data Mesh. The attractive part of the approach is the placement of agreements in the delivery path. Producers publish events through defined interfaces; consumers react to those events; compatibility rules can be checked before a change reaches the consumers that depend on it.

An illustrative domain might publish a status-change event that a reporting service and an operational service both consume. The producer needs to define the event's meaning, identify its schema and support the way that schema changes. A registry and a publishing check can make part of that agreement executable.

That arrangement can expose an incompatible change before it becomes a consumer incident. Its value depends on the rules the registry applies and the paths through which producers can publish. A registry sitting beside an unchecked publishing path offers a description of the contract without enforcement.

Schema validity also has limits. A field can contain a valid status value that describes the wrong business state. A timestamp can be well formed and refer to the wrong event. The product still needs semantic definitions, quality controls and a responsible domain owner. Making the interface machine-checkable strengthens the agreement without replacing those duties.

Choreography gives consumers another useful property. A domain can publish an event without embedding every downstream response in its own code. Each authorized consumer can react through its own handling logic. A dashboard and an operational service may derive different views from the same occurrence.

That independence has conditions. Consumers need to know which event types exist, whether a change is compatible, and how to recover when delivery or processing fails. Publishing an event transfers information. It doesn't transfer responsibility for every downstream consequence to an unnamed other team.

Streaming keeps the mesh's product and ownership requirements while adding questions about delivery, state and recovery. The system has to handle consumers falling behind, processing that accumulates state, and changes that arrive while other work is in progress. A late or repeated event can matter differently from a late batch report.

Backpressure is one of those operating questions. A consumer that can't keep up needs a supported response. Buffering, slowing production or refusing work changes the behavior of the whole path. The choice has to match the product's commitments and the consequences of delayed processing.

Exactly-once processing needs an equally precise scope. A guarantee inside a processing engine doesn't by itself establish that an external action happened once. A workflow that can trigger a real-world change must account for retries and effects at the boundary where that change occurs.

Tools such as Kafka and Flink can participate in such a design. Their presence doesn't settle domain ownership, product meaning or the consumer's recovery obligations. Using a stream to move records into a central warehouse can be a sensible pipeline without fulfilling every principle of a streaming mesh.

The decision therefore depends on the job. A consumer that needs a periodic answer may be served by a maintained batch product. A consumer that must react to events needs a delivery and operating model that supports that reaction. Streaming earns its cost through that need, rather than through the architectural elegance of making everything continuous.

Agent workers sharpen this distinction. Some need a saved result they can reopen. Others need to react when another worker finishes. Both need durable context; only the second requirement starts to justify an event-driven coordination path.

A cold-start contract describes what a worker needs when it begins without the preceding conversation. The phrase can sound more elaborate than the job. The worker needs a clear objective, the relevant context, authority to act, boundaries it must respect and a way to tell whether the result satisfies the assignment.

People need much of the same information. A human team can sometimes recover missing context through conversation or shared experience. An agent's recovery options depend on the tools and permissions it has been given. Some agents can ask questions or retrieve earlier records. Others can do neither. Design the handoff around the consumer's actual recovery options.

I use Agent Redwood to make those choices explicit when scoping agent systems. It's a way to decide what a system needs, rather than a software framework competing with LangGraph or LangChain. Memory, constraints, evaluation, tools and integrations are among the components I consider, then rank by importance and decide how deeply to develop for the job.

The method came out of unfinished projects, including an agentic video-game builder. Trying to build the whole thing from an undifferentiated idea left too much undecided. Breaking the system into explicit design concerns gave me a way to choose what belonged in the first useful version.

That lesson applies to a handoff. Adding more words to an issue can make it longer without making it usable. A worker may receive a detailed vision and still lack the input it's supposed to change, the permission required to change it, or the evidence its owner expects back.

I treat documentation as part of fulfillment. A client who has to ask how to run a delivered system has exposed a missing part of the delivery. The same test applies when the consumer is another worker. The instructions and the result have to support the next action.

Take an illustrative code-review assignment. The work order identifies the exact change, the relevant repository rules and the reviewer's permitted scope. It names the evidence the reviewer should inspect and the form in which findings must return. A replacement reviewer should be able to distinguish the submitted version from an earlier attempt without asking the original author.

The result needs a similar contract. A finding identifies the affected version, points at the relevant passage or code, explains the failure and states what would resolve it. A consumer can then decide whether the finding still applies after the code changes. A general complaint that something looks wrong leaves that reconstruction to the next person.

Self-description has a security limit. A complete handoff contains the information its consumer is authorized to use, with controlled references for anything else. Copying secrets into an issue to save a worker a lookup would create a different failure. A stable reference and an explicit access requirement can be more useful than putting every available detail in the prompt.

The contract also needs a truthful non-success state. A worker that lacks an input should be able to identify the missing dependency and stop the affected action. Treating every interruption as an instruction to improvise encourages the system to manufacture completion out of ambiguity.

A cold start exposes whether a product can be used without its producer standing beside it. The handoff carries enough meaning for its next authorized consumer, and someone remains responsible for keeping that meaning current when the job changes.

A catalog, a rule file and a work-order template all describe some part of a running system. Each can become wrong while remaining easy to read. The failure is especially dangerous when consumers treat the description as authoritative and have no reason to inspect what it describes.

Pair a published record with an operation that detects relevant drift and a responsible party who can correct it. Creating the file establishes neither part of that arrangement.

A capability catalog can compare its entries with the capabilities actually available to workers. The comparison needs to identify a missing entry, an obsolete reference or a mismatch in the details consumers rely on. The catalog then becomes part of an observable publishing process rather than a list maintained from memory.

A rule file raises a different question. If copies exist in several places, the system needs to identify which copy is authoritative and how changes reach the others. A synchronization check can reveal divergence. The repair still needs a policy for deciding which version is correct. Copying whichever file changed last can spread an error just as efficiently as it spreads an improvement.

A work-order validator can reject a missing source reference or an absent acceptance condition before dispatch. Its reach is narrower than the quality of the assignment. A populated field may still contain an incoherent request. Mechanical validation should catch the conditions it can establish, while leaving the judgment it can't establish visible to the owner.

Those examples share a maintenance pattern. The check runs when the underlying thing can change, reports a mismatch against an identified authority, and gives someone a bounded repair to make. A useful failure message tells the owner which agreement broke. An unread log entry leaves the agreement broken.

A pre-action hook can refuse a forbidden operation before it happens. A log records an operation for later inspection. Both can be useful, but a system should describe their consequences accurately. Logging an access violation after data has been sent doesn't provide the protection of preventing that send.

The check itself needs maintenance. A changed publishing path may bypass it. A renamed field may cause it to inspect the wrong input. A failure treated as a warning may allow invalid work to continue. The check's result has to change the action it governs.

Human judgment remains part of the arrangement. Someone determines the policy, approves exceptions and repairs a check that rejects valid work. Automation can reduce repeated enforcement work after that decision. It can't take responsibility for choosing the right rule on behalf of an organization that has never agreed on one.

A committee review and an automated check can expose defects on different schedules. A shorter feedback loop can expose defects sooner, provided the run exercises the relevant path and someone acts on the result. An agent that confidently consumes stale material can otherwise repeat the same failure without making the drift obvious.

This maintenance pattern makes the mesh comparison practical. It lets a team name what keeps a product usable after creation, which is also what a shared agent platform has to supply.

Consider an illustrative review system that receives a code change, assigns the relevant checks and returns a decision a maintainer can inspect. Its consumers are the maintainer deciding whether to accept the change and the implementer who must resolve any findings. A pile of independent agent replies would leave those consumers to do the coordination themselves.

The mesh principles suggest how to organize the work. The mapping below describes responsibilities a system could implement. It makes no claim that every agent platform already has them.

A security reviewer and a performance reviewer can use different context and tools. The security review may need to inspect permissions and trust boundaries. The performance review may need to examine the work performed along a request path. Giving each worker a bounded concern can reduce irrelevant context and make its output easier to evaluate.

Specialization focuses the worker's attention. Domain ownership adds a continuing responsibility for the review product. Someone owns the criteria, maintains its tooling and handles a finding that turns out to be wrong. A role name in a prompt doesn't establish that responsibility. A short-lived agent can perform work inside a domain whose accountability persists outside the individual run.

The boundaries also need a way to compose. A performance recommendation may change the access path a security reviewer is examining. The coordinator must identify such conflicts, preserve the evidence and route the decision to the appropriate owner. Combining outputs into one verdict requires a policy for resolving disagreement.

The data-product properties apply to the review result with little translation. Findings need to be discoverable and addressable. They need enough evidence for a consumer to judge their reliability. Their terms must explain what failed and which version was examined. Shared formats let a coordinator combine findings without guessing which field contains the conclusion. Access controls protect both the code being reviewed and the evidence returned.

A typed result helps establish the shape of that handoff. It can require a finding to identify an affected file or a relevant source. It can't establish that the source supports the finding. A review system needs to keep those questions separate or it will confuse a well-formed accusation with a demonstrated defect.

I use typed data models, APIs and structured observability together in my Python systems work. Explicit input contracts make data easier to exchange, and observable execution makes failures easier to investigate. A review result still needs evidence for its particular finding.

The self-serve part is the machinery each reviewer shouldn't have to recreate. Workers need a way to obtain the authorized input, start in the intended environment, discover supported tools and save results where their consumers can find them. A tool catalog can reduce the need to load every capability into every worker's context.

Deterministic code can handle known operations such as identifying an input version or validating a result's required fields. An agent can investigate a question that needs interpretation. Assigning each kind of work deliberately avoids asking a model to improvise operations the platform already knows how to perform.

Computational governance then connects those operations to the rules. A worker's file access is bounded before it reads. A required check produces a recorded result. A release decision identifies the change and evidence it applies to. Domain-specific checks can differ while the common requirements for identity, authorization and evidence stay consistent.

The analogy has a boundary. Code-review outputs and analytical data products serve different consumers and carry different commitments. A centrally dispatched workflow can borrow mesh principles while retaining centralized coordination. The comparison earns its place when it helps us identify ownership and usable interfaces. It becomes misleading when a matching diagram substitutes for examining those responsibilities.

A review verdict also needs to survive the workers that produced it.

A short-lived worker can disappear while its result remains important. The next worker needs to know what was assigned, which input was examined, what action occurred and what evidence supports the reported outcome. Saving the final answer may preserve some of that information. It may leave out the decision that explains why the worker changed direction.

Durable records need to capture the moments that matter to later decisions. An assignment, a changed constraint, a failed check and an acceptance decision can each change what the next consumer should do.

An illustrative workflow might record an assignment, a dispatch, a worker's finding, a proposed change, a check result and a maintainer's decision. Each occurrence needs a stable relationship to the relevant work and version. A later reader should be able to distinguish a check on the proposed change from a check on the revision that was eventually accepted.

That relationship is what turns a collection of messages into a usable history. A timestamp alone may tell us that a record came later. A link to the input and preceding decision explains what it applies to. Corrections need the same care: a new finding can supersede an old one without pretending that the earlier judgment was never made.

A knowledge system may also need to distinguish when something was true from when the system learned it. Those are the two times a bi-temporal record distinguishes. A decision recorded after the fact can otherwise appear current even though the underlying situation has already changed. Whether a team needs a bi-temporal store depends on the questions its consumers must answer.

A saved record needn't contain every internal step of an agent's reasoning. It needs the decision, the evidence and the consequences required for the job. Capturing everything indiscriminately can make useful history harder to find and can retain information that shouldn't be shared. The consumer's need and the system's access rules still govern the record.

An audit log records occurrences. An event-sourced design uses events as the basis from which application state is derived. A streaming system adds continuous processing and delivery commitments. Those choices can work together, but a worker's short life doesn't make all of them mandatory.

A saved artifact and a database record may be enough for the next task. Event-driven coordination becomes useful when a recorded occurrence should cause another consumer to act. An issue-assignment event can trigger dispatch. A completed review can notify the implementer. The design then needs to account for missed, repeated or failed handling of those events.

Coordination can also combine a central queue with event-triggered operations. A design with no central coordinator is one possible arrangement. What matters to the consumer is knowing which component owns the transition and how an interrupted transition can be recovered.

A worker's statement that it ran a check is a claim. A recorded execution result provides different evidence. A trace showing data pass through the relevant deployed path can support a runtime claim, provided it identifies the right version and operation. A rendered result needs evidence of what was actually shown.

A trace still has a scope. It may show that a tool was called without establishing that the tool's answer was correct. Missing instrumentation leaves some events unobserved. An absence of recorded evidence means a claimed outcome hasn't been demonstrated through that record; it doesn't establish that nothing happened in the world.

Later consumers should inspect evidence that reaches the claim they're relying on. Durable history makes that inspection possible after the worker is gone. Its usefulness depends on the relationships and meaning the system preserves, which brings the argument back to product design.

The economic case for agent systems has to include the work around the model call. An operator pays for preparing context, handling failures, reviewing results and maintaining the tools that make those results useful. A low-priced response can become expensive if somebody has to reconstruct its inputs or repeat the task.

Continuing investment in contracts can reduce the waste of repeated agent work. Self-describing inputs can reduce reconstruction. Validated handoffs can catch malformed output before another worker consumes it. Shared infrastructure can remove setup that would otherwise happen separately for each task.

Those savings depend on the workload. They need to exceed the cost of maintaining the contracts, checks and platform. Agents change some line items in that calculation; they leave people responsible for deciding what useful and correct mean.

Context has a cost beyond its size. A worker given unrelated material has more opportunities to apply a rule from the wrong situation or confuse a historical decision with a current one. A bounded assignment can identify which source is authoritative and which result the consumer needs.

The assignment still has to carry enough information to succeed. Removing a qualification to make a prompt shorter can create a retry or an incorrect result. Self-description means supplying the relevant meaning, not maximizing or minimizing the number of words.

Typed handoffs address a different source of waste. A result that omits a required identifier can be rejected before it reaches the consumer that needs that identifier. The check saves downstream investigation only if its requirement matches the actual consumer. A mandatory field nobody uses adds maintenance without improving the handoff.

Code-navigation indexes and other prepared context can help where workers repeatedly need the same structural information. Such an index also becomes another product to maintain. A stale dependency map can direct a worker toward the wrong code just as a stale data catalog can direct a consumer toward the wrong dataset. The maintenance cost belongs in the comparison.

A spelling correction and a change to an authorization boundary need different evidence. Routing both through the same expensive review process can spend capacity without improving the lower-risk decision. Giving both the lighter review can leave the consequential failure unexamined.

Risk-tiered review asks what can go wrong in this change and which check could establish the relevant condition. A deterministic check may settle a well-defined question. An agent can investigate a broader concern. A person may need to decide a disputed requirement or accept a residual risk. More reviewers are useful only when their work adds evidence the decision needs.

The calculation includes failed reviews. A false finding sends the implementer through unnecessary investigation. A missed defect can reach a user. A coordinator that merges incompatible advice can create another defect. Counting completed reviews without examining those outcomes would measure activity while leaving the value question open.

A per-review model cost alone can't establish the total operating cost of another team's system. Compare maintained handoffs and relevant checks with the reconstruction, rework and failures they can prevent.

A disciplined path becomes sustainable when it helps the people funding it achieve the outcome they care about. The system has to keep demonstrating that relationship. It can start with one handoff whose failure costs enough to matter.

A data engineer moving into agent systems already has useful questions to ask. What does this record mean? Who owns it? Which consumers depend on it? What happens when it changes? The mesh literature gives those questions a developed architectural context. Agent tooling gives them new consumers and some different costs.

The translation is valuable without requiring the claim that both fields have built the same system. A work order can borrow data-product discipline. A review platform can borrow federated standards. An event-driven runner can borrow ideas about contract evolution and consumer recovery. Each borrowing should solve an identifiable problem in the workflow.

Choose a handoff in which missing information creates rework or a decision made on the wrong basis. It could be an issue passed to a coding worker, a dataset passed to an analyst, or a review result passed back to an implementer. Start with the consumer and the action it must take.

The following sequence turns the comparison into a bounded design exercise. It's a way to inspect an existing workflow, not a requirement to rebuild its infrastructure.

The result should change what the next consumer can do. A better packet lets it identify the correct input, act within its authority and return a result whose status is inspectable. A new catalog or validator that leaves the same ambiguity intact hasn't resolved the handoff problem.

Streaming can follow when the consumer's job requires a reaction to an event. Domain decomposition can follow when independent areas of responsibility need different context and different ownership. A shared platform can follow when several consumers need the same support. Each investment answers a demand already visible in the work.

Part one of the trilogy develops a recurring architectural shape: decisions separated from managed state, messages between components and shared representations that let implementations change. It connects objects, functional cores, hexagonal architecture, actors, entity-component systems and compiler intermediate representations. Those ideas come from different settings; their differences remain important.

Data mesh adds the scale of an organization's data products to that comparison. A product boundary resembles a module boundary in the respect that consumers need a supported interface. A shared schema can do some of the work of an intermediate representation. A platform can provide common tools that domain owners use without surrendering their product decisions.

The analogy ends where business meaning, authority and accountability remain unsettled. A successful schema check can't decide which domain should own a disputed fact. An agent can't remove an organization's disagreement by generating a plausible description of its policy. People still need to make those decisions, and the system needs to preserve them accurately.

The mesh finally ships when those responsibilities become operations a consumer can rely on. An agent workflow is one place to build them, with a direct test: replace the worker, reopen the handoff and find out what the next consumer can actually use. The missing explanation belongs in that product, with an owner who keeps it current.