Programmable shared environments for agents
Connect your existing repos, docs, and sheets with capabilities, procedures, role-scoped access, and persistent working state. Different agents can work against the same live pod without reconstructing the environment for each one.
Collections
srcsource codedocsengineering plansdrivecontracts + sheetsnotesagent threadsNodes
one pod surface, scoped by roleRoles
draft + test + commitread + inspectrun + checksToken count and latency are live from the dashboard (30-day window). Savings are estimated per task on benchmarks against a strong native bash baseline.
One piece of work, end to end
Shared working state lives in the pod, so the work can pass between harnesses without being rebuilt from a transcript. Every step below runs against the same handles. Roles make responsibilities visible; enforcement happens server-side on every call. Even the review findings live in the pod — the author reads them where the work is.
plans[auth-timeouts.md].section("Timeout handling")api-server[src/handler.go].expand("Handler").draft.edit(...)api-server.test(targets="api")api-server.invoke("codex", "reviewer", ...)Start in Claude. Resume in Codex.runner["run-…"].read() → ci["run-…"].ls() → commit(...)> plans[auth-timeouts.md].section("Timeout handling")
> api-server[src/handler.go].expand("Handler").draft.edit(...)
> api-server.test(targets="api")
Run dispatched: run-… · Check: ci["run-…"].ls()
> api-server.invoke("codex", "reviewer",
"Review the draft diff and flag risky changes")
Run dispatched: run-… · Check: runner["run-…"].read()> api-server[src/handler.go].draft.diff()
--- a/src/handler.go
+++ b/src/handler.go
@@ -2,7 +2,8 @@
… 1 file(s), +2/-1
> ci["run-…"].ls()
Run [succeeded] · lint: api · test-unit: api> runner["run-…"].read()
> api-server.commit("fix: handler timeout")
Committed and pushed · 6bf424fEngine vs substrate
State is addressable — sections, symbols, rows, and runs are durable handles that let any harness work at a precise scope. Important inputs, outputs, and state transitions stay addressable instead of becoming ad-hoc copies in a transcript.
A pod assembles collections (data) and nodes (capabilities) into one surface. Each connection carries a role, so an agent gets exactly the access you grant.
Any harness can target the same pod. The agent is swappable; the handles, drafts, and results stay put.
Pods and nodes
Each MCP connection uses one pod. Collections connect the organizational state agents work on; nodes add capabilities such as test(), run(), and search(). Roles scope authority, skills carry reusable procedures, and drafts, runs, and results keep working state available across sessions and harnesses.
Collections sync from GitHub, GitLab, and Google Drive — more sources coming. Lynko is the substrate, not the system of record. Your source stays authoritative; supported writes publish back to it.
native:skillsIndexes qualified SKILL.md files across the pod so agents can discover, read, pin, and curate reusable playbooks.
native:ciAdds test() so draft changes can be checked before they become committed state.
native:runnerAdds run() for builds, smoke tests, and commands on a machine you connect over SSH.
native:embeddingAdds search() — semantic search over every qualified collection in the pod.
One URL to connect
No config file — add one URL as a custom connector. The connection is scoped to one pod, so your agent sees that pod's collections and nodes, nothing else.
Custom connector URL
https://mcp.lynko.ai/mcpPaste it into Claude, Codex, or Cursor as a custom connector — dynamic client registration handles the rest.
Early access
Connect one pod, add one MCP URL, and keep the same scoped state across every harness you use.
Free during early access — we'll allowlist you within 24 hours.