Koan
Start with the web and storage your first use case needs. Add identity, jobs or search when the business earns them, and Koan tells you what each one brought with it.
Koi
Koi brings containers, applications and devices into one local fabric: discoverable by useful names, able to establish trust, and ready to communicate across the boundaries that usually keep them apart.
Ghostlight
Let your agent work in the browser you already use. The work stays visible, you keep the wheel, and the runtime stays local.
Zen Garden
A spare computer becomes a named Stone. Ask the garden for MongoDB and it handles the manifest, hardware fit, storage, port and published connection details while the application stays about its own work.
Agyo
When a Koan application needs GraphQL, scheduling, vector search, RAG or another advanced capability, add that intent without introducing a second framework around the domain.
Shiguchi
Teach an agent what a calendar, operator or sensor means once. Shiguchi gives each capability class a small, versioned contract and defines the observable behavior every implementation must prove.
os-tools
Small, dependency-light Rust crates that each present one identical API over the platform-native mechanism beneath - the same operation, done the same way, on Windows, macOS and Linux. The first is os-truststore: it installs a root certificate into the OS trust store, where the established crates in this space only read from it.
Hokora
A research canon, not software: an architecture paper, a glossary, a graded bibliography and a stack of decision records for how an artificial companion might remember, attend, and hold a coherent sense of self over time.
Nagi
A paced-breathing companion built to be held rather than watched. A tuned, runnable prototype exists today. The shippable app is the next thing.
- You want a small web application with storage running before scaffolding becomes the project.
- Identity, tenancy, jobs, search or agent access should join when the business case earns them.
- Developers and agents need one compact grammar, with runtime decisions people can inspect.
A minute with Koan
Start useful
Reference the first capabilities, describe the domain, and have a real web application with storage running on day one.
Add the next need
A new reference brings the next coherent capability into the same application model, with configuration only where the choice needs it.
Read the business
Entities, rules and workflows remain the application. Repeated infrastructure mechanics stay in the framework.
Composability is the product.
Koan is a family of capabilities sharing one composition model, added in the order your domain and use case require.
Business domain + Web + Storage + Identity + Tenancy + Jobs + Search + MCP
Add only what the use case earns. The boot report, capability set and composition lock explain what each reference contributed.
What it looks like from where you sit
For the developer
Each small addition lands a useful vertical slice - route, storage, rules and all.
For the agent
One grammar to learn, in place of archaeology through the repository to guess at the wiring.
For DevOps
Startup, health and composition evidence say what actually assembled, so a deploy holds no surprises.
For the architect
Capabilities join through shared, inspectable boundaries, so growth stays inside one architecture.
Make one
Install the template, generate an application, run it. What you get on the first run is a persisted, queryable HTTP API.
Ask the API the template just generated:
curl http://localhost:5000/api/todos
Entity, controller, done. The data you POST there is persisted, queryable, and still present after a restart.
Where it stands today
- Data, web, cache, jobs, vector and MCP all work in current source, with integration and conformance coverage behind them.
- V1 is consolidating Koan around a durable Entity contract and explicit acceptance gates. That is the work I am doing now.
- Templates and packages ship on NuGet as Sylin.Koan.*. Upgrade guarantees, observability and error polish are the parts still settling, and the APIs are not locked until 1.0.
A minute with Koi
On your workstation
See the databases, development servers, containers and devices already around you, then give the ones that matter names that survive the next restart.
Across your homelab
Let native applications, containers and physical devices participate in the same local network without rebuilding the stack around a new control plane.
Inside a private fleet
Give people, scripts and agents one current picture of what can be found, trusted and reached.
Start by looking
Before Koi asks you to shape the network, let it answer one useful question: what is already here? Install the v1 release candidate for your platform, then look.
Browse the local network now:
koi mdns discover
Discovery runs on its own. If the result earns a permanent place, keep Koi running and add useful names, trust and deeper connectivity in the order your network needs them.
Find. Trust. Connect.
Three outcomes, carried by one living view of the local environment. Use the part you need first; let the rest join as the network grows into it.
service appears -> found by a useful name -> trusted where needed -> connected across its boundary -> removed when it leaves
The same lifecycle is visible through the CLI, dashboard, APIs and MCP, so people, applications and agents are talking about the same network.
What it looks like from where you sit
For the builder
Describe what a service offers once. Koi carries discovery, naming and participation across operating systems and runtime boundaries.
For the operator
See arrivals, health, restarts and departures through one coherent local story while keeping the DNS, proxy and monitoring tools already in place.
For the agent
Begin with current environmental context instead of spending the first exchange probing ports, reading stale host files and guessing what is still alive.
- The job needs a site where you are already signed in.
- You want browser work to stay visible and interruptible.
- Several page states, tabs, forms or evidence sources belong to one workflow.
A minute with Ghostlight
Work where you are signed in
Use the Chromium profile that already has the session the job needs, without copying credentials into a separate browser service.
Watch and take over
The agent works in a dedicated visible tab group. Pause, interrupt, or use the browser yourself whenever you need to.
Recover and continue
Exact workspace identity and useful next steps help work survive ordinary page, tab, and connection changes.
Useful first. Responsible all the way through.
Ghostlight starts with the job: see the page, act in the browser, and return a compact result. Visibility, boundaries, and evidence belong to that same experience.
MCP client <-> ghostlight-mcp-connector <-> ghostlight service <-> ghostlight-browser-connector <-> extension <-> Chromium
The three executable roles and the extension run locally as the current user. No Ghostlight-hosted control plane sits in the runtime path.
What it looks like from where you sit
For you
One installer and visible, interruptible work.
For the agent
Stable schemas, compact results, and useful recovery guidance.
For reviewers
Local evidence, readable source, and an inspectable boundary.
Try it for real
Let your agent handle setup, or run the installer yourself. Both paths end at the same doctor check.
Check the whole chain
Doctor names anything missing.
Open https://example.com/ in a new Ghostlight tab, summarize the page, and tell me which tab you used. Do not click, type, submit, or change the page.
You should see a dedicated Ghostlight tab group, the exact tab used, and a summary produced without a click, form write, or page change.
Four ways to try it
Start with the read-only check above. These four bounded recipes show the other jobs Ghostlight is built to carry without turning the page into a tool catalog.
01 Complete a safe launch briefSynthetic form work
Prompt
Open https://sylin.org/ghostlight/demo/brief/ in a new Ghostlight tab. This is a simulated form. Set Project to Moonlight Notes, Owner to Maya Chen, and Summary to "Turn field observations into a shared release brief." Enable Include screenshots and Keep data local, then select Create brief. Stop when the page confirms the brief is ready for review.
What you should see
A visible read, deliberate field changes, one submit action, and "Moonlight Notes is ready for review."
Success boundary
Only the synthetic Sylin demo changes. Nothing is sent or stored.
02 Read authenticated work without copying credentialsUser-chosen signed-in page
Prompt
Open [SIGNED-IN APPLICATION URL] in a new Ghostlight tab using my current browser session. Confirm the account or workspace name visible on the page, summarize the current page, and list the next available actions. Do not click, type, submit, or copy credentials.
What you should see
The chosen application opens with the browser profile session, and the answer reports visible context without changing the page.
Success boundary
The person chooses and confirms the account. Do not record or quote the result without permission.
03 Follow one exact browser-created childTab continuity
Prompt
Open https://example.com/ in a new Ghostlight tab. Add a temporary link labeled Open child proof that points to https://example.org/ and opens in a new tab, then click that link. Follow the browser-created child and report the title and URL of both the original and child tabs. Do not close either tab or change either site.
What you should see
One exact child becomes usable without a manual context refresh, while the source tab stays open.
Success boundary
The temporary DOM change stays in the disposable example.com tab. Ambiguous popups are refused rather than adopted.
04 Combine page, console, and network evidenceRead-only diagnosis
Prompt
Open https://sylin.org/ghostlight/demo/foundry/ in a new Ghostlight tab. Start console and network tracking, reload once so page-load events are captured, then inspect the page, console, and network buffers. Report any failed request or console error, distinguish observed evidence from inference, and recommend one next check. Do not modify the page.
What you should see
The answer separates page state, browser events, and inference. Finding no error is a valid result when the evidence is clean.
Success boundary
The single reload is explicit because console and network tracking begins when first requested.
Where it stands today
- The trained browser schemas are stable and I am holding them steady. The interfaces around them will still change before 1.0.
- Windows and Linux are verified end to end against live browsers. macOS builds and passes the full test suite in CI; its live-browser verification is still owed.
- The Chrome Web Store serves Chrome adapter v0.8.0. Chrome adapter v0.8.0 covers Ghostlight service versions v0.8.x. Install the extension from the public listing.
- You have thin clients, retired PCs or other capable machines that should be useful instead of becoming e-waste.
- You want a handful of self-hosted services without hand-maintaining container commands, ports and hostnames.
- You value local ownership, comprehensible infrastructure and the freedom to replace individual machines.
A minute with Zen Garden
Prepare a Stone
Boot the garden installer on a spare machine. It receives a name, an identity and a place in the garden.
Offer what you need
Name the service. A checked-in manifest carries the operational knowledge for selecting, placing and starting it.
Find it by meaning
Ask for MongoDB, not a remembered box. Rake returns the current location and a connection URI for people, scripts or agents.
Useful machines, working together.
Useful hardware, tended as one garden.
Zen Garden starts with service intent, then carries that intent through placement, operation and discovery. The container is disposable; the offering name, configuration, data location, port and discoverability are what the garden remembers.
What's inside
spare machine -> named Stone -> offer manifest -> Moss -> running service -> connection URI
Moss tends the runtime on each Stone. Rake, scripts and agents inspect the same garden; Koan applications can resolve zengarden:// resources into current connection strings.
What it looks like from where you sit
For the builder
One service-shaped request replaces a page of container, storage, port and discovery plumbing.
For the agent
Compact commands plus JSON and URI output keep infrastructure work legible and composable.
For the operator
Pulse, health, events, logs and visible companions make the garden observable in software and in the room.
For the inheritor
Named offerings and checked-in manifests preserve why a service exists after its original machine is gone.
Grow one useful thing
Once a Stone is running Moss, two commands turn service intent into something an application can use.
Open the live terminal view when you want the whole garden in sight:
garden-rake pulse
Pulse makes Stones, offerings and current state visible without turning ordinary service use into an operations dashboard.
Where it stands today
- The offering lifecycle, discovery, operations and companion surfaces all run on a real mixed-hardware garden, and you can test them from source.
- The USB creator builds an unattended Stone installer today. A signed turnkey image is still on my list.
- Moss can rebuild a missing managed container on a surviving Stone. Cross-Stone state recovery, guarded update rollback and real high availability are what I am working on next.
- A Koan application needs an advanced capability without a parallel bootstrap, domain model or provider vocabulary.
- A small application should gain something substantial without letting integration plumbing dominate its code.
- Optional dependencies and their security cadence should remain outside Koan core until an application asks for them.
A minute with Agyo
Name the capability
The reference says what the application needs. Agyo carries the recurring registration, lifecycle and provider mechanics.
Keep one application
Entities, hooks, configuration and business behavior stay in Koan's familiar grammar instead of splitting into another integration layer.
See what joined
Capabilities participate in Koan's startup and operational vocabulary, so optional composition can remain inspectable.
Capability without a second architecture.
Agyo is where useful Koan-native capabilities can grow independently. Applications reference only what they need; the foundation stays lean and the resulting system stays recognizable.
What's inside
Koan application + chosen Agyo capability -> AddKoan() -> one composed runtime
Agyo depends on Koan's public packages; Koan never depends on Agyo. That one-way boundary keeps every capability optional and gives it an independent release and security cadence.
What it looks like from where you sit
For the developer
The capability arrives; the code you are left reading is still about your application.
For the agent
A known package and one composition grammar, in place of invented wiring.
For DevOps
Visible dependencies, health and provider choices, with defaults that are safe to ship.
For the architect
A controlled frontier that lets Koan stay coherent instead of growing into a monolith.
Follow Agyo toward V1
The capability source works and is testable today. Published packages and compatibility guarantees are part of the V1 work.
Where it stands today
- Twelve library projects pack from source, the principal composition paths have focused tests, and Librarian is a substantial runnable service assembled entirely from Agyo capabilities.
- There is no NuGet release yet - the first Sylin.Agyo.* packages and a clean package-first path in are part of the V1 work. Follow the source if you want to track it; package IDs and APIs are open until that release.
- Some boundaries are deliberate: scheduling stays in-process, GraphQL typing is still limited, the AI, vector and Vault paths need their providers running, and the full tool-using RAG loop is still ahead of me.
- You build agents, hosts or workflows that should survive a change of provider without learning another tool dialect.
- You publish an agent-facing capability and want a checkable contract rather than a self-described compatibility badge.
- You need to adapt an existing server once, review the mapping and make every approximation or gap visible.
A minute with Shiguchi
Speak the capability
An agent targets an exact semantic identity such as calendar create-event instead of carrying every vendor's spelling and schema in working memory.
Know the claim
A compatibility statement names the exact profile, baseline, facets and fixture digest it passed. Prose can explain the contract; fixtures decide it.
Keep the ceiling
A frozen projection can welcome an existing server while its coverage manifest and passthrough surface preserve what the shared profile cannot express.
The joint holds because the shapes agree.
Shiguchi standardizes the small semantic surface agents can rely on, defines the behavior both sides must prove and leaves vendor-specific reach visible instead of sanding it away.
What's inside
capability appears -> exact class + baseline + facets -> native or frozen projection -> fixture-backed claim -> agent uses one known interface
Capability Class Profiles add semantics, not another transport. Profile verbs remain ordinary MCP tools, so an unaware client can still call them while a profile-aware client can select and verify the exact contract.
What it looks like from where you sit
For the builder
One contract per capability class replaces one integration grammar per vendor, while exact versions keep old workflows intelligible.
For the agent
A small vocabulary, canonical examples and stable schemas put more task intent in each token and make the next action easier to verify.
For the publisher
Native support or a reviewed projection creates a precise adoption path; coverage shows where the provider exceeds or falls short of the shared contract.
For the ecosystem
Apache-2.0 contracts, a neutral namespace and a written transfer path keep the shared language open beyond its first steward.
Start with a contract you can inspect
Shiguchi is specification-first today. The useful first result is understanding one complete agent-facing contract and seeing the behavioral cases that define it.
Now inspect the corresponding behavioral scenarios:
cat shiguchi/profiles/calendar/fixtures/core.fixtures.json
The fixtures make patch preservation, cancellation tombstones, free-time correctness and loud unknown-ID failures concrete. The runner that will execute them is still unbuilt.
Where it stands today
- Draft 0.2. The normative concepts, descriptor, conformance, projection, kernel, facet and composite documents are all written - as drafts, not published baselines, so none carries a conformance digest yet.
- Calendar is the worked reference profile, with JSON, an agent skill and a Core fixture suite. Operator has a draft contract, skill, Core and facet fixtures, and a Ghostlight-derived Vendor example. Neither has an independent implementation passing yet.
- The reference runner, wrapper and playground are specified but unbuilt. Commands like shiguchi test and shiguchi wrap describe where this is heading, not something you can install today.
- Most catalog classes are still sketches without fixtures. I am proving the runner and the validation slice before growing the catalog any further.