ToWow studies how a relationship could form
The research asks how actors might discover one another, express capability, align intent, and negotiate roles, including who should work together on what.
AGENT-TO-AGENT · TRUST BOUNDARIES
Trust is not a switch.
Trusted and untrusted agents both need identity, authority, records, verification, and acceptance. The real divide is this: when another participant may err, conceal, or actively attack, what still makes those things credible?
RELATIONToWowStudies discovery, negotiation, and relation formation
MAY COMPOSE WITHWORKFlownessKeeps work, judgment, and evidence continuous
DOES NOT REPLACEBOUNDARYSecurity & TrustDecides who can do what and which evidence can be accepted
Conceptual composition, not a claim that these roles are deployed as one product stack.
The core judgment
Inside a trusted domain, a harness mainly prevents work from distorting. Across an untrusted network, it must also prevent identity, authority, and evidence themselves from being forged.
01 · THREE DIFFERENT JOBS
Forming a relationship, sustaining work, and establishing security are different jobs.
They connect to one another, but none can stand in for another.
Flowness keeps work continuous
Preserve work identity, context, versions, findings, evidence, and acceptance. It asks how a task can survive a change of agent without distortion.
A security layer makes the boundary hold
Authenticate identity, constrain capability, isolate data, resist abuse, and handle disputes. It asks what remains impossible to bypass when a participant is not trusted.
Flowness offers governance and acceptance mechanisms that a ToWow deployment could compose with. This page does not assert a current product integration. Flowness is not a complete zero-trust security layer, and it does not replace identity, cryptography, privacy, or anti-collusion mechanisms.
03 · WHERE THE PATHS SPLIT
Share a skeleton. Do not share assumptions.
The distinction is not whether there is a log, but who writes it. It is not whether there is a judge, but who proves that the judge did not collude. Location, affiliation, and ownership alone are not enough to establish trust.
TRUSTED DOMAIN
Trusted agents
They share an operating party, organizational relationship, or explicit cooperative constraint. The main risks are error, drift, and excessive authority.
- 01Identity starts with organizational relationships
Participants belong to the same team, operating entity, or explicit partnership. Accounts, roles, and workspaces can be a starting point, but they do not replace artifact identity.
- 02The main defense is against unintentional distortion
Typical risks are context drift, use of an old version, concurrent overwrite, local testing presented as completion, and reviewers sharing one blind spot.
- 03Authority limits blast radius
Even trusted participants should not all receive deployment credentials, production database access, or write access to the main branch. Reversible workspaces and least privilege still matter.
- 04Internal systems can be truth sources
Where governance relationships are clear, an organization event ledger, repository, database, and accountable acceptance can jointly establish authoritative later state.
UNTRUSTED DOMAIN
Untrusted agents
Participants can be self-interested, compromised, or actively hostile. The risk expands from work done incorrectly to the source of fact itself being fabricated.
- 01Identity must be verifiable
A display name, session ID, or self-description is not identity. Authentication, signatures, nonces, replay protection, and defenses against impersonation and Sybil behavior are required.
- 02Inputs and evidence may be manipulated
Log writers, validators, judges, and external data sources can fail or act maliciously. Evidence needs provenance checks, isolated recomputation, and sometimes an external witness.
- 03Authority must be structurally narrow
Capability tokens, sandboxes, secret isolation, data minimization, and default denial are not only engineering discipline. They prevent one compromise from becoming a system-wide compromise.
- 04Collusion and dispute need explicit handling
Several judges are not automatically independent. A system still needs to address collusion, malicious vetoes, false scoring, privacy leakage, abusive traffic, challenges, appeals, and accountability.
04 · WHAT FLOWNESS CAN ESTABLISH
Governance structure matters. It does not create trust by itself.
Keep a judgment intact through handoff and rework
The public Open Alpha demonstrates a narrow but load-bearing path: isolated producers, bound candidates, independent review, mandatory findings, targeted rework, and a fresh verdict for a successor candidate. That verdict is not a target-domain Effect or responsible-party acceptance.
Identity, confidentiality, and production authority need their own foundations
The public security policy does not promise production security, reliability, isolation, or scale. Alpha workers should not receive unreviewed credentials or irreversible production authority.
Events, judges, and evidence become objects to verify
In a trusted domain, separation of duties can provide strong internal control. With unfamiliar or adversarial participants, authentication, signatures, capability constraints, external witnessing, anti-collusion measures, and dispute handling may also be necessary. A2A defines interoperable communication, not a replacement for each agent's authorization model.
05 · CURRENT EVIDENCE BOUNDARY
Separate what is demonstrated now from what remains a design boundary.
Flowness Assurance Kernel
The public repository supports reproducible execution, independent review, targeted rework, and a fresh verdict on a successor candidate. This supports the assurance kernel, not target-domain Effect, responsible-party acceptance, or every broader Flow Engineering claim.
Do not infer external-network guarantees
This page does not claim that ToWow implements A2A, that unfamiliar external identities can initiate contact, that a server relay is end-to-end encrypted, or that the current product is a zero-trust production system.
Strict isolation and least authority remain requirements to establish
Default isolation, least authority, and consent before connection are engineering directions. A2A, NIST, and OWASP are design references for per-operation authorization and risks such as goal hijacking, tool misuse, privilege abuse, insecure inter-agent communication, and cascading failures. They are not public verification of a product implementation.
Complete Flow and general cross-domain runtime
The Flowness README keeps complete organic goal-to-accepted-outcome flow and a general cross-domain Flow runtime as open questions. Design, private dogfood, and public runnable evidence are not interchangeable.
06 · SIX QUESTIONS BEFORE YOU CONNECT
Ask these six questions before connecting another agent.
- 01
Are these agents operated by the same party and inside the same authority and audit domain?
- 02
If an agent, judge, or log writer lies, what lets the system detect it?
- 03
What is the largest blast radius of one leaked credential or malicious action?
- 04
Are the candidate artifact, validator, and acceptance decision bound to exact versions?
- 05
When a dispute occurs, who may challenge, recheck, revoke, or make the final decision?
- 06
Which data must collaboration share, and which data should never leave its original trust domain?
07 · PUBLIC SOURCES
For claims about public capabilities, return to the current repository.
Evidence reviewed on 2026-08-18. Product boundaries constrain this wording; they are not evidence of a public implementation.
CONTINUE