#Why Orfyn?

AI doesn't fail in the demo. It fails after.

A model that answers well in a sandbox tells you almost nothing, because production failure looks nothing like a wrong answer. It looks like an integration surface the model cannot reach. Two systems whose fields share a name but not a meaning. An approval branch the demo never exercised. A permission boundary that works only for the engineer who built it. An upstream schema that quietly moved three months after go-live.

The role invented to close that distance is the forward deployed engineer: someone who sits inside the business, learns how it actually operates, translates that into something buildable, ships it, and owns the outcome afterwards. It works — and it is headcount. Every enterprise is hiring for the same scarce people, capacity grows one engineer at a time, and the context walks out the door with them.

Orfyn is that role as a platform. The same loop — understand the business reality, define the right problem, build where it cannot hurt anything, verify against the real rules, own the changes after go-live — run by coding agents on your infrastructure, under your review.

#The boundary model

Everything about the architecture follows from one rule: the work happens inside your boundary, and your data does not cross it.

• The daemon runs on your hardware — a laptop, a company server, a container in your network. It manages the agents; clients (desktop, mobile, web, CLI) connect to it locally or over an end-to-end-encrypted relay that carries ciphertext only.
• Model calls leave on your credentials. Your Claude subscription, your OpenAI account, your own API keys, a self-hosted endpoint. Orfyn does not proxy model calls and is never in the data path.
• Files and instructions stay local. Agents work against your real repositories on your machines. The Teams coordination layer carries assignments, status, and transcripts — not your code.
• Access is granted, not downloaded. Every deployment is licensed and provisioned by the owner-admin. Nobody runs Orfyn against your systems without you having said so, including us.

#What the agents actually do

• Discovery. Read the systems involved as they actually are — schemas, permissions, integration surfaces — not as the diagram says they are.
• Field mapping. Two systems rarely disagree loudly; they disagree quietly, in fields that share a name but not a meaning. The mapping is made explicit and reviewable.
• Build in isolation. Each piece of work runs in its own workspace and worktree, with per-worktree services and ports, so parallel work cannot collide and nothing lands unreviewed.
• Verification. Against your rules: the status transitions, approval branches, and permission boundaries that decide whether the thing is actually correct.
• Operation. Change requests after go-live run through the same loop. The context accumulates in the system, so the second change costs less than the first.

#Architecture facts that matter

• macOS, Windows, and Linux are all primary targets — none is a port.
• Mobile, desktop, and web are separate native clients; the mobile app is React Native, not a webview.
• Voice runs on-device by default; cloud speech providers are opt-in.
• The CLI exposes the same surface as the app — anything in the UI is scriptable, and agents can drive Orfyn themselves: create isolated workspaces, spawn subagents, open terminals, send prompts.

#What it isn't

Not a hosted agent — it runs where your systems are. Not an IDE — it drives the agent CLIs you already use and stays out of the way. Not a model provider — the credentials, and the relationship with the model vendor, remain yours.