Is fdelink replacing tools like Claude Code and Codex?

No. Those are the harnesses; fdelink is the governance layer above them. Your people keep the CLI they like, and fdelink brings the workers running on those tools into the organization — giving them boundaries, keeping the ledger, running the evaluations, and carrying profile, memory and task context across when the harness changes.

Is “swap the model at will” really seamless?

Two layers. Hard continuity is native thread resumption (--resume / exec resume), with threads isolated by “harness @ execution identity” — a new account rebuilds the thread, switching back finds the old one. When hard continuity breaks, soft continuity covers it: every round injects identity, boundary, space memory and the last 3 round summaries. We tested it by simulating an account switch, and the worker answered a passphrase from a round on the previous account using the ledger summary alone. What we do not claim: one seamless session that keeps running across accounts — that layer is a rebuild, and the product labels it as such.

Can a worker overstep — say, send internal material outside?

The boundary is a server-side constraint, not a polite line in a prompt. Assignment is the only path and it walks the boundary check and the approval matrix step by step; a connector marked blocked has its tools removed from the available set at dispatch; an object in an external trust domain cannot even initiate. Calling the API directly meets the same decisions.

Can you alter the audit records yourselves?

Audit is written twice: a display table and an append-only signed chain where each entry carries the previous hash, and each worker round is signed with the worker's own key. Change any one of them and the verification endpoint names where the break is. Verification is in your hands — you don't have to trust our word for it.

Can the company see the personal work I do?

It depends on ownership. Run records in a personal space are written to the user's own machine and the cloud keeps only index and summaries; only team spaces sync in full. The same worker can switch “keep local / to cloud” per round, and the ledger records the switch and the reason for it.

How do you tell whether an AI worker is actually any good?

Test items come from real tasks, not from public leaderboards. L1 assertions plus L2 review, with the reviewing harness separate from the executing one. The same items run on two harnesses: a gap under the threshold means the bottleneck is the worker's gene (prompt and configuration) rather than the model. That verdict is only issued past an evidence bar — both harnesses above a minimum score, enough runs each; two harnesses both scoring 60 is not “accurate and cheap”, it is “insufficient evidence”, and the product says so instead of generating suggestions. With only one harness sample, no attribution is made.

How fdelink works: six requirements, the loop, and running it

Core concepts

What does it take to treat an AI agent as a long-term employee? Six requirements

Each one lands in the server and the execution layer — not in a UI label that says “governed”.

01 / Long-term worker

Identity and context continue across harnesses

Two layers, labelled separately. Hard continuity is native thread resumption, isolated by “harness @ execution identity” — same harness, same identity, the thread resumes. Switch harness, account or device and a new thread is opened; we never force-resume another account's session. Soft continuity then rebuilds context from identity, boundary, space memory and the last 3 ledger summaries. We do not claim “one seamless session across accounts”.

Lifecycle standby → running → idle → archived; archived ≠ deleted

02 / Loop engineering

Keep the loop running, keep judgment with people

Any item can be promoted to a loop: each round the worker reports done / todos / gate / whether the goal is met, and maintains its own backlog. When a human call is needed it raises a gate into “waiting on you” — and if other work is available it does that instead of idling.

Two rounds with no structured report → a gate is raised automatically, quota isn't burned

03 / Signed custody chain

Audit proves itself; verification is yours

Every worker and every person holds an ed25519 identity, and each worker round is signed by the worker. Audit is written twice — a display table and an append-only signed chain where each entry carries the previous hash. Change any row in the database and verification names the break.

/api/chain/verify is open — don't trust us, check

04 / Two-track data ownership

Private work stays local, team work goes to the cloud

Pick ownership when syncing: run records in a personal space stay on local disk and the cloud keeps only an index and summaries; team spaces sync in full. The same worker can switch “follow / keep local / to cloud” per round.

What the promise really means: delete the cloud database and your personal output is still on your own disk

05 / Skills and connectors

Connect once, use everywhere; credentials never enter the worker process

Skills and MCP configuration are scanned from the actual machine and synced up; for credentials only the environment-variable key name is recorded — values never reach the database. Connectors get one of three policies: unrestricted / read-only declaration / hard-blocked at execution, where a blocked connector's tools are physically removed at dispatch.

Loosening a policy from blocked → logged as [high risk] in audit

06 / Evaluation and gene iteration

Test items come from real work, not from leaderboards

Items are generated out of real tasks: L1 assertions plus L2 review, with the reviewing harness kept separate from the executing one. Scoring on two harnesses gives attribution — but only past an evidence bar: both harnesses must clear a minimum score and a minimum number of runs. Below it the product shows the numbers and says “insufficient evidence”; no gene-improvement suggestion is generated from it.

One harness, no attribution; an unfinished round scores an invalid 0

One closed loop

How does a local AI agent become a governed asset of the organization?

Discovery and sync are the entrance, boundary and approval are the gate, ledger and evaluation are the return path — complete one turn and the organization owns an asset that depends on nobody's computer.

gate where a human must be present runs automatically write-back: this turn's result is the next turn's starting point

Deployment

How do you self-host an AI agent governance platform inside your own network?

One codebase, three stores: out of the box it is a single SQLite file; point it at Supabase and it uses the relational model with RLS.

Runtime

Containerized, one command to serve

Multi-stage build (front end compiled → the runtime image carries only artifacts and server source), runs as non-root, and tini forwards SIGTERM so a graceful shutdown actually receives the signal.

Liveness /api/health (never touches storage) · readiness /api/ready (actually touches it)

Data boundary

Self-hosted; data never leaves your network

Request-scoped multi-tenant isolation + database RLS. Personal-domain run records stay on the user's own disk while the cloud keeps only index and summaries, and for credentials only environment-variable key names are stored.

Signing keys go into the customer's KMS at delivery

Portability

Before you switch machines, you get the truth

The portability ruling walks local harnesses, skills and connectors item by item and decides for each gap whether it can be auto-filled; one-click repair restores skills into local directories, and same-name-different-content is refused rather than overwritten.

No pretending it will run

What is fdelink

How do you get fdelink running? Five steps

From an empty machine to a governed worker with a signed ledger entry. Steps 1–2 take minutes; step 3 is the one that needs a human decision.

1

Step 1Deploy the server

One container, one command. Out of the box it is a single SQLite file; point it at Supabase and it uses the relational model with row-level security.
docker run -p 8422:8422 --env-file .env fdelink
2

Step 2Discover what already runs

fdelink scans the machine for agents, skills and MCP configuration actually present, and strips credential values on ingest — only environment-variable key names are recorded.
3

Step 3Declare boundary and ownership

Grant the capabilities the worker may use and choose whether its output belongs to a personal space (stays on local disk) or a team space (syncs in full). Without a boundary the worker cannot be assigned work at all.
4

Step 4Assign work

Assignment is the only path in. Each task walks the boundary check and the approval matrix before any harness is invoked; blocked connectors are removed from the tool set at dispatch.
5

Step 5Read the ledger, run the evaluation

Every round is signed by the worker's own ed25519 key and appended to a hash-linked chain you can verify yourself. Test items are then generated from the real tasks the worker performed.
GET /api/chain/verify

fdelinkOverview Governance & securityBook a demo