What Syns is, why it exists, and what we hold to be true.

This guidebook says what Syns is and why.

The parts

• I · Why we exist — the beliefs, and the ambition they force.
• II · The ladder — why markdown, why sharing, why a product. Three steps; each depends on the one before.
• III · The problem: what goes wrong when agents work from what someone wrote down about a client, and the same problem in a developer team.
• IV · The answer — what Syns is, in layers, and what we refuse to build.
• V · The objections — why nobody built it, why the alternatives fall short, who the neighbours are.
• VI · Who it is for: client-service teams first, developer teams second, the buyer, and who we turn away.
• VII · Come back here — one-screen reference cards. Open these mid-conversation.
• Glossary — every term we use, one line each. Dotted underlines in the text jump here.

Syns rests on four statements about where software development is going. None has a date. The argument depends on the direction, not the pace.

The flip

Today code is the asset. We read it, review it, maintain it, and fear breaking it.

When agents write the code, the asset flips.

Code becomes disposable. The specification becomes the durable artifact.

The asymmetry is exact. From a good specification you can rebuild the software. From the software you cannot rebuild the specification.

Code holds a decision's consequence. It never holds the decision.

Where this leads → 3 · The ambition. The beliefs as a list → 22 · The beliefs.

Building does not go away. It moves.

A good specification removes ambiguity about what the software should do.

A good process turns that specification into working software reliably.

With both in place, the code is no longer something to audit. We trust the result because we trust the process that produced it.

Because the process is reproducible, we can generate the software again and get the same outcome.

Code quality becomes a consequence, not a concern.

What the builder now does

• Writes and maintains the specification — the boundaries, the trade-offs accepted, the things deliberately not built.
• Designs the workflow the agents follow.
• Builds the evaluations that prove the process works.
• Reads the reasoning, not the diff.

The work ahead is not making agents smarter. It is building the specifications, the workflows, the evaluation systems and the interfaces that make this real inside engineering teams.

That is the work Syns is for.

Why the spec has to be written at all → 9 · Why write it down.

Syns is the product form of the beliefs in chapter 1.

Syns hosts the reasoning that produces code. GitHub hosts the code.

The reasoning is the deliberate artifacts: plans, specifications, architecture decisions, configurations, the files that guide an agent to build software.

Syns does not host code. It does not train or tune models. It builds the engineering layer around them: storage, versioning, access control, coordination, discovery.

Code is the first case, not the boundary

Belief 3 and the case for sharing hold wherever an agent does the work from what someone wrote down.

A consultant's brief on a client is to the proposal what a specification is to the code. It is the durable object the output is produced from. A new session cannot recover it from the output. And it has to be shared when the work is.

The go-to-market leads with that case: client context. The argument below is written for code because the product was built on it.

Every belief maps to a design choice

Without the beliefs, Syns makes no sense

• If code is the asset, GitHub is enough.
• If reproducibility does not matter, versioning specifications is pointless.
• If models alone will solve it, no infrastructure is needed.
• If humans still write most software, coordination for many parallel agents is overbuilt.

Hold the beliefs fully, and something like Syns is inevitable. The beliefs are the thesis. Syns is the product.

The short form → 21 · Syns in one breath.

Markdown is the native input and output of every coding agent.

An agent works by reading files, writing files and running commands. Its skills, its memory, its plans and its instruction files are already markdown. Working in markdown asks it to learn nothing and install nothing.

Cloud agents do not change this

Belief 2 moves the agent off your laptop into a sandbox. A sandbox has a filesystem and a shell. A cloud agent reads and writes a markdown file exactly as a local one does.

What disappears when agents leave the laptop is the shared disk. That is what makes the next rung mandatory rather than convenient.

The case, strongest first

1. Zero integration. A database, a document platform or a vector store needs a tool call, a schema, and a decision about when to write. A file appears as a side effect of working.
2. No schema in advance. The shape of agent reasoning is not known up front. The sections, the wording and the layout of the folder emerge from the work. Text holds a thought that has no field yet; structure is added only where it has emerged.
3. Human-inspectable, and a change is readable. The person holding the intent must be able to read and correct it. A changed sentence is readable in any editor. A restructured JSON blob or a database row is not.
4. Cheaper than a document platform. Reading a Google Doc or a Notion page through its API costs a lossy round-trip on every access. A folder of markdown is the cheapest thing an agent can work on.
5. It survives us. A folder of markdown outlives the product, the vendor and the format decision. Leaving Syns costs one download. That is what makes trusting a hosted service safe.

Next rung → 5 · Why sharing. The alternatives to files → 16 · Why not X.

Human teams shared knowledge beside the code for decades: a Slack message, a standup, a comment on the Linear ticket.

Those channels were built for a human reader. The reader is now an agent.

An agent starting a task does not read yesterday's Slack thread, was not in the standup, and does not open the ticket unless told to. What it reads is the files in its working directory.

What has to be shared is the markdown itself, as files an agent will load — not a summary a human types into a chat.

Under belief 2 this stops being a preference

Two agents in two sandboxes have no shared disk.

Either a layer built for it synchronises the reasoning between them, or each works from whatever happened to be in its sandbox when it started.

Next rung → 6 · Why a product. The problem this produces → 7 · Nowhere to live.

This is the question a developer asks first: why not GitHub? The answer has two steps. A consultant asks a different first question, about the AI's own project; that answer is in chapter 16.

Step one — the reasoning gets its own repository

Agents iterate on the reasoning far more often than on the code. A plan is rewritten twenty times while the code it describes changes once.

Kept in the code repository, that rate of change has two bad outcomes and no good one:

• Commit every turn, and the code's history is mostly agent text.
• Commit once, and the progression that made the document worth keeping is thrown away.

There is no right commit granularity for a document a machine is thinking through. Commit granularity is a human editorial decision, and there is no editor.

Some agents produce no code at all. An agent using markdown as memory has nothing to commit alongside. A consultant's agents never do.

The reasoning also has a different shape from code, and the difference shows in four places:

• Non-developers work in it. A change in business strategy reorganises the backlog and rewrites what will be delivered. Product, design and management people make that change. The codebase is untouched while it happens.
• It is true regardless of branch. A decision holds whichever branch of the code you have checked out. A file that lives inside a branch cannot say that.
• It spans repositories. Requirements and decisions live outside any single code repository. One project can reference the decisions and context of another. Specs, changes and planning context are separable from the code they describe.
• It moves faster than the code. Ideas are explored and iterated in the reasoning long before — and often without — a codebase update.

So the reasoning goes in a repository of its own, or it damages the one it lives in.

Step two — that repository does not belong on a code host

Once the reasoning is separate, a code host is a general-purpose remote holding an artifact it was not built for.

• Many agents write it in parallel, on many machines and in many sandboxes, and every one has to be current without anyone running a step.
• Changes arrive continuously and in small pieces. No human decides when a thought is finished, so there is no commit to make. What you want to inspect is not a flat list of commits but what an agent was working on, what context it held, and how its change affected the other documents.
• Nothing in a code host reads the text for whether it still means what it meant.

What works for code — branches, pull requests, review, a human at the keyboard — does not work for files updated continuously by machines and consumed by machines.

What a purpose-built host does instead

• Keeps every copy current across every agent, with no ceremony to set up.
• When one agent changes a file while another is working on it, rejects the stale write instead of silently overwriting a teammate's.
• Says things about the whole set of documents a code host has no reason to say: which concepts are duplicated, which statements disagree, what the agents actually read.

Where a team already keeps a separate planning repository, the argument is never against their structure. It is that the remote underneath it can do more.

The full head-to-head, including GitHub → 16 · Why not X. Why nobody built this → 15.

What a consultant knows about a client is the input to everything they produce for that client.

Who the client is. What was decided and why. The brand and the template. The past work worth reusing. The option deliberately not proposed.

The output cannot hold it. A proposal holds a decision's consequence, never the decision. So it has to be written down, and the agent has to read it before it starts.

Every session begins with re-explaining the client.

The briefing lives in the consultant's head, in old chats, in a pasted block of context, or in one vendor's project. Each new session, each second AI and each colleague starts without it.

Four things make it worse for this audience

• It does not reach the colleague. What one person told their AI about the client stays with that AI. The colleague gets a file on Slack, does not read it, and either asks again or produces work that contradicts it. The cost is not only rework but a colleague who stops using their own judgement.
• It multiplies by the number of clients. A team holds several briefings at once, and every switch is another re-brief.
• It is locked to one vendor. What one assistant was taught, another cannot read. Keep one project per vendor and every correction has to be made in each copy by hand.
• It is spread across companies. The material sits in the firm's own drive and in each client's accounts, often a different suite per client. A product that stores context per company account cannot follow a team across other companies.

The tools a consultant already has were built to share knowledge between humans. The agent is the consumer now, and it cannot read the call notes, the inbox or the colleague's head.

This is the reason someone goes looking for somewhere to put the briefing.

The same problem in a developer team

Every agent session produces code and the reasoning behind it: the plan, the decisions, the alternatives rejected. The code goes to the code repository. The reasoning stays on whichever machine produced it.

Two agents in two sandboxes have no shared disk. Either the reasoning is synchronised between them by a layer built for it, or each works blind.

The second problem, which arrives once this one is solved → 8 · Intent drift.

The written briefing is what the agent reads before it starts. It is only worth reading while it matches what was agreed.

Intent drift is when the written briefing stops matching what was agreed, and nothing tells you.

A client changes the target in a call.

One copy of the brief is updated and another is not.

Nothing breaks.

The next session reads the stale copy, treats it as the brief, and produces work that is fluent, confident and wrong: off-brand, off-target, built on a decision the client reversed.

The consultant finds out when the client does, and absorbs the rework.

Two properties make it expensive

• It is invisible while reading. A stale sentence reads as well as a current one. The only detector is the person holding the whole picture.
• It compounds. Each drifted brief is the input to the next piece of work, so the error is repeated rather than corrected.

Three ways a briefing decays

Why the human fix stops working

The workaround is to re-read the brief after every change and correct it by hand. That loop is right, and it leaks in three places.

1. Reading costs time a busy consultant stops paying.
2. A stale sentence reads perfectly well, so it is skimmed past.
3. A correct fix in one copy silently leaves another wrong.

The third leak ends the loop. Nobody decides to stop checking. The cost exceeds the perceived benefit, and after that drift is unbounded.

This is the reason someone who already shares the briefing keeps paying.

The layer that catches it → 11 · Three layers. Why a spec at all, given this → 9.

A specification is a second thing to maintain, and it can disagree with the code. That disagreement is exactly the failure chapter 8 describes. So: no spec, no drift. Why not let agents work from the code plus the conversation?

The objection is argued here for code. It holds the same way for a client briefing and the work produced from it: code is the first case, not the boundary.

Five reasons the objection fails

• Code cannot hold the decision. You can read what the system does. You cannot read the trade-off that was accepted, or the alternative that was rejected.
• Negative space cannot be written in code. "We deliberately did not build X" has no expression in a codebase. The absence looks identical to an oversight, and an agent will helpfully add X back.
• The specification has a different shape from the code. It holds business context, priorities and plans that change without the code changing, and that non-developers own. Code has nowhere to put them — see chapter 6.
• Inference is neither free nor stable. Working intent out from the code costs context on every run, and produces a slightly different answer each time. Writing it once and reading it is cheaper and deterministic.
• Drift is a detectable failure. Absent intent is an undetectable one. A spec that disagrees with the code can be found and fixed. Intent that was never written down cannot be checked against anything.

Where the objection wins

One person, one agent, one short-lived project. The intent fits in a head and a context window, and a specification is overhead.

That case is real. It is not who we build for — see 18 · The profile.

A repository in Syns is a versioned collection of the markdown files that tell agents what to build.

Specifications, plans, architecture decisions, configurations, instruction files, retrospectives.

Not source code — that stays where it is. Not transcripts or prompts — those are how an agent got somewhere, not what it decided.

For the wedge, that collection is a client's briefing: the brief, the brand rules, the decisions, the past work worth reusing.

Everything in a Syns repository got there because someone or something decided to write it down.

That one sentence separates Syns from every memory database and every session recorder. We store deliberate artifacts, not inferred state.

The loop

Each step, one line

1. Set up. A person points an agent at the setup skill. It reads what is already written (a codebase, existing markdown, what is known about a client), asks what it cannot infer, and proposes a structured wiki. It ends with a review page showing every source, the existing markdown, the proposed structure, and which fact came from where. Nothing is invented, the old structure is backed up, and everything is revertible.
2. Sync. Every agent session updates from the shared state before its first turn and sends its changes at the end of each. The wiki is current on every machine and in every sandbox without anyone running a step. Nothing sits inside the agent's reasoning loop.
3. Work. People and agents store, read, review and collaborate on the markdown.
4. Health. Syns will score the wiki from two independent sources: structure checks (frontmatter valid, links resolve, dates fresh) and each agent's behaviour against its own baseline (a session that normally makes three edits making fourteen). Either alone is gameable.
5. Repair. A separate agent will fix the structure so the problem does not come back. It never reverts; it fixes on top. It has to be separate because the agent that went wrong does not know it did, and cannot read across sessions.

Health and repair belong to the third layer, insight (chapter 11). They are direction, and are spoken of in the future tense.

How it works underneath, one line each

• An update is one unit. A set of changed files becomes exactly one new version. There is no half-applied state.
• Only what changed travels. Unchanged files are sent as fingerprints. A large repository with one changed file costs a kilobyte on the wire.
• Stale writes rejected. An update declares the version it last saw. If another agent has sent an update since, yours is rejected rather than silently overwriting their work. The agent then reads the other's work and adjusts.
• Full history — per repository, per file, per agent, per turn — with revert to any point.
• Teams and roles. A private repository is indistinguishable from a non-existent one to anyone without access.
• Every action is recorded from the first day. Deleting a repository does not delete the record of what happened to it.
• Tool-agnostic. It does not care which agent or methodology wrote the file, and it sits underneath the workflow tools, not in front of them.
• Plain files you can leave with. A folder of markdown outlives the product and the vendor. Leaving costs one download.

The principles as a list → 23 · The principles.

The answer to Part III is three layers. The order is load-bearing: the third exists only on top of the first two. That is the whole reason a purpose-built product can exist here.

L1 makes drift detectable in principle. L2 makes the briefing work across clients, vendors and colleagues, and creates the drift that matters most, between copies and agents that never meet. L3 is the only part a customer cannot assemble themselves.

The full sentence, worth knowing by heart:

What a person knows about their work cannot be shared with agents by the tools built for humans, and once shared it drifts from what was agreed, silently and cumulatively. The only place either can be fixed is a persistent, shared, versioned record of what every agent read and wrote. Syns is that record, and the instruments over it.

One L3 concept worth knowing → invariants. What only we can hold → 13.

Keep this list separate from the next chapter. This is what a customer feels. Chapter 13 is what a competitor cannot copy. They are different lists.

Where value lands first

Setup and not re-explaining. Not health, not repair.

The sequence a customer feels: one client's briefing gets set up from what already exists, the next session starts from it instead of from zero, a second client follows, and then a colleague's agent works from the same files.

The failure it is measured against: a context block pasted into every chat, one project per vendor with the copies drifting apart, and a colleague who cannot use any of it.

L3 is what makes the value permanent, not what makes it start.

Checking output scales with what the agents produce, which only goes up. Checking the briefing scales with the briefing, which is bounded and can shrink.

That asymmetry is the answer to anyone who says checking AI output is already their bottleneck.

Individually weak, jointly hard to copy. This order is not the order that shows best in a room.

1. The vendor-neutral, tool-agnostic position. An assistant vendor that charges per seat or per token gains nothing by making a rival's model better, so each vendor's shared context stays one-vendor. This protects only a customer who mixes assistants. Whether this audience does is the first thing every conversation checks.
2. It follows the work across companies. A client-service team's working knowledge spans its own accounts and each client's. Products that store context per company account are not built to follow a team across other companies, and the platforms have no reason to build for an audience this small. That buys time, not safety.
3. The read⋈version join. Which agent read which lines, when, against what the file said at that moment. Assistant vendors see reads for their own agent only. Observability tools see reads without file versions. The join exists nowhere else, and only a layer that does both the sync and the hooks can hold it. Every L3 instrument and every invariant check is made of it.
4. The template library. Proven structures per kind of engagement, tagged and carrying usage knowledge. Every briefing set up teaches the next proposal.
5. Accumulated versioned knowledge, and eventually a public library with forking and attribution. A network effect; not load-bearing yet.
6. Sync itself — multi-agent coordination and the managed infrastructure under it. The demo, not the advantage that lasts.

Plain files are part of the case, not an advantage that lasts. A folder the customer can leave with lowers the risk of adopting a hosted product, and a platform whose value is keeping the customer in will not offer it. It is on the list in chapter 12 and off this one.

What we deliberately do not try to own

Contradiction detection, duplication detection, over- and under-specification checks, the removal check.

These run as verification steps inside the templates, on the customer's own model, client-side. Syns interprets and visualises their output.

Three consequences, all intended: the cost sits visibly on the customer's side; further commoditisation costs us nothing; and the market improving these checks improves Syns for free.

They are on the advantage list in chapter 12 and off this one. That is the most consequential product decision we have made.

Lead demos with sync. Build the business on the first four.

The thing that shows best is last on the list. The thing worth most is hardest to show.

Why not the tracker, at length → 16 · Why not X.

Why hasn't GitHub, Cursor, or a frontier lab shipped this?

They are shipping it, each inside its own walls.

The assistant vendors ship shared projects that hold a team's files, instructions and memory. Each works best with its owner's model, inside one company account. A harness vendor attaches a session link to every commit.

The neutral versions are workspaces, not files. Several vendors' agents can read and write their pages, but the last edit wins and nothing rejects a write made against an outdated copy.

The gap that leaves

• A customer who mixes assistants is served by none of the vendors' own projects.
• A vendor that charges per seat or per token gains nothing by making a rival's model better.
• Work that crosses company accounts is out of reach of any product that stores context per company account.
• The layer that crosses the walls is the gap: plain files every agent reads first, stale writes rejected, tied to no provider.

The honest risk

The weak spot is a team on one vendor, where that vendor's feature is good enough. The residual risk is a platform deciding to host neutral context itself, or acquiring the neutral player. Say that plainly when asked; dodging it costs more than naming it.

Where the vendor moves are tracked → 17 · The neighbours.

Two tests. The first asks whether a channel can move the artifacts at all. Several alternatives pass most of it. The second asks whether it can tell you the artifacts went wrong. Nothing on the list passes that.

Test 1 — can it move the artifacts?

Test 2 — can it tell you the artifacts went wrong?

Nothing in either test is exotic. The alternatives fail on ordinary criteria.

The alternatives

The substitutes a consultant reaches for come first. The ones a developer team reaches for follow.

The grid

No alternative is bad at everything, and several clear most of test 1. What separates the list is test 2: the columns that are the argument, and the columns we cannot yet demonstrate. For Syns, D1 and D2 are the third layer, insight, marked → as direction.

Two rows to read first. The AI's own project, because it scores well for exactly one vendor and the grid cannot show that. And the hand-kept brief, whose C7 hides that publishing costs nothing only on the machine the file is already on.

Alongside the tools they already use

A consultant's deliverables live in the client's suite, and a developer team's work lives in its tracker. Keep both.

• Replacing either is a different and much harder business. Nothing in the wedge requires winning that fight.
• The deck, the ticket and the report are where work is delivered or tracked. The briefing is what an agent reads before it works.
• An agent updates a markdown file in the same motion as doing the work, with no second tool and no "remember to update it".

The counter to have ready: the client's suite and the tracker hold markdown too, and agents can write them by API. The API path is a separate act of publishing to a remote system — exactly the step that gets skipped.

The short answers for a conversation → 27 · When someone asks.

The category is called spec-driven development, or context engineering, depending on who is talking. All of it produces markdown as the durable artifact of agent reasoning.

Client work has no category name at all. The same object, what a person has written down about a client and the agent reads before it starts, ships as a feature of the assistant (projects, memory) or of the workspace, never as a category of its own. Nobody searches for it; people describe the symptom.

The workflow tools are complements

A dozen tools — from a solo maintainer's viral repository to first-party offerings from Microsoft, Amazon and Google — do a variant of the same five steps:

1. Intercept the user's request to a coding agent.
2. Force a structured workflow: clarify → spec → plan → implement → review.
3. Produce markdown artifacts.
4. Store them locally, in a tool-named folder — openspec/, .specify/, .planning/, conductor/.
5. Drop the user back into the agent to run the plan.

Because step 4 is always local and always theirs, none of them sync across machines, keep history beyond local git, share a set with attribution, coordinate several agents on one set, or say anything about whether the markdown is still true.

They produce the artifacts. Nothing in the list stores, coordinates or analyses them. Each one that says "the store is just a git repo" is a socket, not a competitor.

Seven families that share the premise and differ on the object

Two more shapes

• Execution platforms that carry context as a line item. A factory-model product takes tickets to PRs on its own infrastructure and includes a memory layer on the menu. Nobody has to decide to compete with us; a bundled line item removes the reason to buy a dedicated layer.
• Vendor-native provenance. A harness vendor attaches a session link to every commit by default. One session, one vendor, read-only, nothing synced or reused. The first sign of an incumbent moving toward the provenance end.

What would change our plans

• A workflow tool ships its own hosted sync.
• A code host or a cloud platform ships a hosted spec service.
• An agent-native VCS adds markdown-aware analysis or a shared hosted set of documents.
• A plan workspace adds consistency checking across all its plans.
• A retrieval-first knowledge base preserves the authored files, or joins reads to versions.
• The schema bet wins — teams accept that intent belongs in a schema. This is a premise risk, not a competitive one.
• An assistant vendor ships shared, version-checked team context. It would hold much of the mechanism for that vendor's users by default; what stays out of reach is a customer who mixes vendors or whose work crosses company accounts.
• A workspace that hosts any vendor's agents adds versioned edits that refuse stale agent writes. The difference then narrows to files against pages.

The standing bet: none of these actors ships a vendor-neutral, versioned coordination layer over the written context in the near term. The assistant vendors ship shared context inside their own walls; the gap is the layer that crosses them.

A tripwire fires an investigation, not a conclusion. A move that looked like a threat on a README paragraph has turned out to be an integration opening on the documentation.

The bets as a list → 24 · The bets.

Boutique agencies, studios and consultancies where several people work on the same client, each with their own assistant. Headcount predicts the pain badly. Three other things predict it well.

Why the problem is this profile's

What one person told their AI about the client never reaches the colleague's AI.

The colleague gets a file on Slack, does not read it, and either asks again or produces work that contradicts it. The cost is not rework. It is that the other person stops using their own judgement and copies the examples they were given instead.

Two things make it this profile's rather than everyone's. It vanishes for someone who works alone, so the assistants' memory features, built around one person, do not reach it. And the team's material crosses companies, so a product that stores context per company account cannot hold it for the whole team.

A founder-led product team has the first and not the second, which is why it comes second. A solo fractional has the second and not the first, which is why it is a doorway.

The order we approach them in

Ranked by whether the pain vanishes for someone who works for one company alone, and whether a platform would have to break its own account model to fix it. The research found evidence per group, never per sub-niche, so the order is judgement.

Inside the first shape, firms whose material sits under strict confidentiality terms, strategy and due-diligence boutiques above all, wait for an answer on hosting.

The qualifying signal

They describe the client brief not reaching a colleague, or not being read, before we mention it.

A brief sent round on Slack that nobody reads, a colleague asking again for what was already told, work that contradicts what was agreed. In a founder's words, from the notes of his first call: "The current method of sharing these files via Slack is ineffective because team members do not consistently read them."

Re-explaining the client to the AI is the hook, not the signal. Everyone who uses AI on client work says it, which is why it opens the conversation; it needs no second person, which is why it does not separate this profile from any other.

Its sharpest form is a team that already keeps one project per client and hit its wall: a colleague could not use it, the copies drifted across assistants, or the output ignored a rule that was in another copy. They already believe the briefing should be written down. Ask what broke.

Three questions every first conversation asks, because the case depends on them: when two of you work on the same client, how does what one of you told the AI reach the other's?, which assistants does the team use for client work, and do you keep any of this in Notion, a shared drive or one shared project already?

The secondary profile: developer teams

The first profile Syns was built and sold for. Their scenario is project specification, and it is the argument of Parts I to V. Return to it as primary when conversations with the primary profile keep pulling toward code.

• Dispatchers, not agents or headcount. Two or more people starting agent runs on one system without checking with each other. One architect who serialises everything runs many agents and sees no conflicts.
• Coupling, not size. Tightly coupled codebases where several people or agents touch interconnected parts. Cleanly segmented work, each piece owned by one person, feels it much less.
• Document maturity. Teams that document nothing yet and want the structure built for them, and teams whose markdown drifts, are both in. Teams already sharing markdown well are not.
• Their signal is a coordination or consistency failure in their own words: "my agents keep undoing each other", "the plan file said one thing and the code did another."
• Solo developers using any workflow tool are the doorway: larger, lower urgency, with a hundred substitutes.

The profile on one card → 26 · Who we target.

• The owner or a partner buys, for the firm. No procurement: at two to ten people the person who feels the pain holds the card or sits next to whoever does.
• It is the firm's tool, carried into the client's world. The client never buys it, but the client's rules on where material may go can veto it. Ask early.
• Adoption fails on workflow change, not on value. The condition: it works through the assistant each person already uses, runs in the background, and asks nobody to learn anything. A pitch that implies changing how they work loses at this step regardless of argument.
• The buying frame is time back and output they can hand over. Not re-explaining, colleagues who work from what was agreed without asking again, and no rework the client should never see. Not contradiction counts, health scores or token spend.
• Willingness to pay is shaped per seat, and the paid tier starts at the second person on the same briefing, conditional on the workflow not changing. A price is not set.
• In the secondary profile, the CTO or VP Engineering buys, collapsing into the founder under about twenty engineers, and the frame is velocity at month six against week one.

The motion, per segment

Two things never to open with

• The product. With the primary profile, the first message asks about the pain and names no product: when two of them work on the same client, how what one told the AI reaches the other's, and which assistants they use. The product comes once they have described the pain in their own words.
• Cost or tokens. The evidence splits by organisation scale, and leading with cost to the wrong half is falsifiable in the room.

• People who want a hosted alternative for source code. That is GitHub.
• People who want a real-time collaborative editor. Permanent, not staged. Someone who wants a cursor next to a colleague's is a disqualification, not a "later".
• People who want a prompt marketplace.
• One assignment at a time, or AI used occasionally. No client to switch between and no briefing worth keeping.
• Work whose confidentiality terms block a hosted product. Deferred to an answer that does not exist.
• Large firms with rigid workflows and long procurement, even where the pain is real and even where they engage. Engagement is not qualification.
• In the secondary profile, teams already sharing markdown well.