I have been experimenting with a methodology called TIED — Token-Integrated Engineering & Development — for coordinating AI coding agents.

The basic idea is simple:

An agent should not merely be told what to do. It should be given an explicit semantic source of truth, a controlled sequence of allowed transitions, and evidence requirements for moving forward.

The interesting part is that the gating is not the product logic. It is a control plane around the agent. It manages the conditions under which the agent may interpret, plan, modify, verify, and hand work back.

The problem with “just give the agent the task”

An agent can produce a plausible implementation from an ambiguous request very quickly.

That implementation may still contain silent assumptions about:

• what a term means;
• which behavior is actually required;
• where a module boundary belongs;
• who owns data or side effects;
• what failure behavior is acceptable;
• whether a test proves the intended behavior;
• whether the implementation changed the architecture;
• whether the written plan is now stale.

The agent is not necessarily being careless. The workflow has simply given it too much authority to invent missing meaning.

TIED as structurally distributed interpretation

TIED does not ask each layer to translate or model the whole system. Interpretation is deliberately distributed across bounded artifacts, each responsible for one kind of claim:

 DISTRIBUTED INTERPRETATION shared vocabulary names and distinctions REQ obligations and rationale ARCH boundaries, ownership, trade-offs IMPL operational behavior and contracts RED tests falsifiable examples of required behavior GREEN implementation executable behavior composition evidence proof that the parts are connected quality evidence risk-specific observations and close-out no layer is the complete model 

System-level meaning emerges from the composition of these layers and the checked relationships between them. A layer can be precise without pretending to be complete.

This is intentionally different from building a whole-system ontology. A monolithic ontology is pressured to absorb every distinction, relationship, rule, and exception. As it grows, it becomes harder to govern and easier to mistake the model for the system. TIED imposes structural limits instead. The vocabulary layer can name concepts, demote synonyms, and record naming bridges, but it cannot absorb obligations, architectural trade-offs, operational logic, or proof. Those belong to REQ, ARCH, IMPL, tests, and evidence.

The vocabulary therefore stays small not merely through editorial discipline, but because it participates in a larger control system with explicit ownership boundaries.

Claims and relationships are given stable semantic identities such as [REQ-*], [ARCH-*], and [IMPL-*]. The token is not the meaning, and no single layer contains all of it. Tokens let tools and agents preserve identity while the layers contribute different, checkable parts of the interpretation.

The emerging architecture

The architecture now looks less like “one agent edits a repository” and more like a set of cooperating layers:

 HUMAN AUTHORITY meaning, scope, risk, exceptions, approval | v +-------------------------------------------------+ | SEMANTIC CONTROL | | vocabulary, REQ, architecture, implementation | | contracts, non-goals, invariants | +-------------------------------------------------+ | v +-------------------------------------------------+ | AGENT COORDINATION | | prompt type -> checklist -> tracker -> tasks | | dependencies -> allowed next transition | +-------------------------------------------------+ | v +-------------------------------------------------+ | EXECUTION | | RED tests -> GREEN code -> composition -> E2E | +-------------------------------------------------+ | v +-------------------------------------------------+ | EVIDENCE CONTROL | | tests, lint, consistency, provenance, QA, sync | +-------------------------------------------------+ | failure or divergence | v +-------------------------------------------------+ | LEAP | | update IMPL first; ARCH/REQ if scope changed | +-------------------------------------------------+ 

This is why I think “agent instructions” are becoming something closer to workflow architecture.

The prompt is only one input. The durable coordination comes from the contracts, state, evidence, and transition rules surrounding the prompt.

Gating is a control plane

A gate should answer:

• Is the agent allowed to enter this phase?
• What must already be true?
• What evidence must be produced?
• What does failure block?
• Who can approve an exception?
• What information must be handed to the next agent?

For example:

REFINE -> ambiguity cleared -> vocabulary resolved -> scope and non-goals recorded PLAN -> REQ approved -> architecture boundaries recorded -> implementation contract exists IMPLEMENT -> pseudo-code validated -> RED tests exist -> module boundaries are explicit COMPOSE -> independent module validation passed -> binding inventory exists -> composition test exists CLOSE OUT -> tests and lint pass -> TIED records are consistent -> divergence is reconciled or explicitly unresolved 

The gate does not decide what the business behavior should be. It decides whether the agent has enough authority and evidence to perform the next kind of work.

There is one nuance: some gates, such as clarification and constitution gates, project domain constraints into the workflow. They still do not implement the product behavior; they determine whether the behavior is sufficiently specified and admissible to proceed.

Other principles that seem to matter

1. Resolve language before reading everything

TIED treats vocabulary as an agent-control layer, not a glossary added after the fact.

The workflow uses four actions:

RESOLVE ambiguous wording to a preferred term PRELOAD only the relevant domain context RECORD new distinctions and naming bridges VALIDATE names across docs, tests, code, and records 

This matters because “task,” “job,” “event,” and “request” may look interchangeable until persistence, retries, ownership, or ordering are involved.

2. Put behavior in an intermediate representation

The IMPL pseudo-code is intentionally more precise than a typical design note. It records:

INPUT / OUTPUT / DATA / CONTROL PRE / POST / EFFECTS FAILURE_MODES DATA_TRANSITION TERMINATION 

Tests and code are derived from this behavior contract. If implementation reality disagrees with it, the disagreement becomes visible instead of silently redefining the specification.

3. Separate unit correctness from connection correctness

Two individually green modules can still fail when connected.

TIED therefore treats bindings as first-class evidence:

trigger -> callee -> arguments -> effect -> ordering -> failure behavior 

CLI, MCP, IPC, and event wiring should normally receive composition tests without hiding the problem inside a full UI-driven E2E test.

4. Make proof boundaries explicit

This is probably one of the most important principles.

valid YAML != valid traceability valid traceability != runtime correctness runtime correctness != security evidence security evidence != product acceptance 

Generated Markdown is useful for navigation, but it is not intent. A green dry-run is useful, but it is not runtime proof. A passing mocked unit test is useful, but it is not provider compatibility.

Every evidence source should say what it proves and what it does not prove.

5. Use risk-triggered rigor

Not every change needs every possible ceremony.

A baseline functional change may need unit and composition evidence. A persistence change may additionally need migration and recovery evidence. An external-input change may need abuse cases. An AI-enabled boundary may need prompt-injection, authorization, sensitive-data, and unsafe-output checks.

The absence of a specialized check should be an explicit applicability decision, not an accidental omission.

6. Keep observation separate from authority

Research findings, operational feedback, and inferred changes do not automatically rewrite canonical requirements.

The flow is:

observation -> candidate finding -> triage -> human or policy adjudication -> reviewed proposal -> canonical REQ/ARCH/IMPL change -> regression evidence 

This prevents the agent from promoting every discovered behavior into “what the system ought to do.”

7. Make the workflow itself typed

Different work deserves different agent behavior:

question debug new feature refine an existing plan build an approved plan close out a change ordinary local work 

The prompt-type router and subagent contracts make those distinctions explicit. A question agent should not mutate the repository. A build agent should not quietly reopen an unapproved design. A close-out agent should not create a commit as a side effect.

This is coordination through explicit interfaces rather than natural-language inference.

What has actually been demonstrated?

The repository has implemented and exercised these ideas through:

• token and cross-reference validation;
• pseudo-code structural validation;
• strict RED → GREEN development loops;
• independent module validation;
• UI-free composition tests;
• deterministic lifecycle and revision checks;
• idempotent creation and atomic publication;
• stale-view detection;
• read-only fidelity research;
• reviewed feedback and LEAP proposal promotion;
• risk-specific evidence manifests;
• offline and brownfield-safe workflows.

The feature-orchestration work has also been built in separately validated batches, with recorded test and consistency evidence at each promotion point.

That is evidence that the method is operationally implementable. It is not yet scientific evidence that TIED always makes teams faster or that it guarantees correct software.

Where the method can still fail

TIED can preserve a bad interpretation very efficiently.

It can fail when:

• the vocabulary chooses the wrong distinction;
• the requirement is incomplete;
• the architecture records a poor boundary;
• the IMPL contract misses a failure mode;
• tests share the same wrong assumption;
• mocks hide environmental incompatibility;
• quality evidence uses an unrealistic workload;
• a reviewer approves a bad decision;
• someone bypasses synchronization;
• the gates become ceremony without useful evidence.

The method does not eliminate judgment. It tries to place judgment where it matters and make the distributed interpretation inspectable.

The current thesis

I would describe the emerging theory this way:

AI agents need less freedom to invent intent, but more structure for translating approved intent.

TIED attempts to provide that structure:

humans approve meaning agents propagate meaning validators check structure and identity tests observe bounded behavior quality tools record risk-specific evidence LEAP repairs divergence humans return for meaning, risk, authority, and exceptions 

The goal is not to trust agents because they sound confident.

The goal is to give them a controlled coordination environment in which unsupported progress is difficult, divergence is visible, and routine propagation does not require a human to reinterpret the entire project at every layer.

I am curious whether others are seeing the same pattern: are reliable agent workflows becoming less about prompt quality and more about control planes, intermediate representations, typed handoffs, and evidence-gated state transitions?