Koan
An opinionated, agent-native .NET meta-framework. Add what the business needs; keep the application readable.
Koi
Let containers, applications and devices find, trust and talk across your private network.
Ghostlight
Your real browser, for any MCP agent - visible, local, and yours.
Zen Garden
Turn spare computers into a small, sovereign service garden. Ask for what you need; Zen Garden tends the machinery beneath it.
Agyo
Opt-in capabilities for Koan. Add more reach without giving the application a second architecture.
Shiguchi
Open, testable contracts for what agent-facing capabilities mean. Learn the class once; change the vendor without changing the job.
os-tools
Small Rust crates: one symmetric API over divergent platform mechanisms.
Hokora
A cognitive-architecture canon for artificial companions.
Nagi
A breathing companion you hold, not watch.
A minute with Koan
From V0 to V1 in meaningful, small steps. Reference only what the use case needs; Koan composes it around the domain and shows what changed.
Start useful
Reference the first capabilities, describe the domain, and run a real web application with storage - without speculative layers.
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.
Is this your problem?
- 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.
- You want zero framework coupling or intend to assemble every infrastructure layer yourself.
- Your application depends on behavior outside the capability contracts Koan and its adapters expose.
- You need stable 1.0 compatibility guarantees or a mature commercial ecosystem today.
Composability is the product.
Koan is not a stack every application adopts at once. It is a family of capabilities with one composition model, added in the order the 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.
One experience, understood from every side
For the developer
Business progress per change: each small addition delivers a useful vertical result.
For the agent
More business intent per token: one grammar replaces repository archaeology and invented wiring.
For DevOps
Certainty per deployment: startup, health and composition evidence say what actually assembled.
For the architect
Growth without architectural drift: capabilities join through shared, inspectable boundaries.
Run one real slice
The current supported public path builds from the active source branch. Start the sample, then create and read persisted domain data through its composed web surface.
Now ask the generated entity surface for the data it persisted:
curl http://localhost:4998/api/todo
The response is useful; the startup report and lockfile are the receipts for how it came to be.
Know what you are adopting
- Work in progress: the V1 initiative is consolidating Koan around meaningful incremental growth, a durable Entity contract and explicit acceptance gates.
- The central data, web, cache, jobs, vector and MCP paths already function in current source and carry integration or conformance coverage.
- Pre-1.0: packaging, first use, errors, observability and upgrade guarantees are still being hardened. Build current source and expect movement.
A minute with 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.
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.
One experience, understood from every side
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.
A minute with Ghostlight
Give an agent the browser where your work already lives. The work stays in front of you, and a boundary is there when the job needs one.
Ask naturally
Describe the job. Familiar browser tools and useful errors keep the agent moving.
Watch it happen
A dedicated tab group opens in signed-in Chromium. Every action stays visible.
Stay in control
Take over anytime. Boundaries explain themselves; the local record shows what happened.
Is this your problem?
- The agent needs the cookies, SSO or sessions already in your browser.
- You want one browser surface across MCP clients.
- You want visible work, easy recovery and inspectable boundaries.
- You need headless, stealth, bulk or remote-cloud automation.
- No person will be responsible for the browser session.
- Claude's first-party browser integration already fits the entire job.
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 <-> relay <-> local service <-> relay <-> extension <-> Chromium
No vendor service sits in the runtime path. Your browser session stays on your machine.
One experience, understood from every side
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://sylin.org/ghostlight/demo/form/. Fill the form with the name Test Gardener, the email [email protected], the Developer role, and the message First light. Submit it, then tell me exactly what confirmation appears. Stay on sylin.org.
Nothing is sent or stored.
Know what you are adopting
- Pre-1.0: the trained browser schemas are stable; surrounding interfaces may evolve.
- 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 listing remains under compliance review; until it is public, the install guide provides the current release-extension path.
A minute with 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.
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.
Is this your problem?
- 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.
- You need a managed service, contractual availability or commercial support.
- You need production high availability, general cross-Stone state replication or automatic disaster recovery today.
- You are operating a large, hostile multi-tenant estate that calls for enterprise orchestration and policy controls.
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.
One experience, understood from every side
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.
Know what you are adopting
- Active development: the offering lifecycle, discovery, operations and companion surfaces are exercised on a real heterogeneous garden and are testable from source.
- The current USB creator builds an unattended Stone installer, but a signed turnkey image or downloadable installer bundle is not published yet.
- Moss can reconstruct a missing managed container on a surviving Stone. General cross-Stone state recovery, guarded update rollback and production high availability remain active work.
A minute with 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.
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.
Is this your problem?
- 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.
- The application is not built on Koan or the team wants zero framework coupling.
- You need stable public packages, compatibility guarantees and a mature support ecosystem today.
- You need durable distributed scheduling, a fully typed production GraphQL schema, or turnkey hosted RAG now.
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.
One experience, understood from every side
For the developer
Meaningful capability without integration sprawl: the remaining code stays about the application's work.
For the agent
More optional intent per token: a known package and one composition grammar replace invented wiring.
For DevOps
Optional operational weight with visible dependencies, health, provider choices and safe defaults.
For the architect
A controlled capability frontier that lets Koan remain coherent without becoming monolithic.
Follow Agyo toward V1
The capability source is implemented and testable today. Public package installation and compatibility guarantees are part of the V1 stabilization work.
Know what you are adopting
- Building toward V1: twelve library projects pack from source, the principal composition paths have focused tests, and Librarian demonstrates a substantial runnable service assembled from Agyo capabilities.
- Not public yet: the first Sylin.Agyo.* NuGet release and a clean package-first onboarding path are still part of the V1 work. Follow the source now; do not treat package IDs or APIs as stable.
- The boundaries are deliberate: scheduling is in-process, GraphQL typing is still limited, external AI/vector/Vault behavior needs its providers, and the full tool-using RAG retrieval loop remains future work.
A minute with 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.
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.
Is this your problem?
- 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.
- You need one vendor's full, irregular API surface today; use its native tools or a projection's passthrough surface.
- Your problem is transport, discovery or tool routing rather than shared capability semantics; Shiguchi deliberately builds on those layers.
- You need a stable 1.0 ecosystem, a published runner or independently verified conformance claims now; this is still a draft.
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.
One experience, understood from every side
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.
Know what you are adopting
- Draft 0.2: the normative concepts, descriptor, conformance, projection, kernel, facet and composite documents are present, but draft artifacts are not published baselines and carry no conformance digest.
- Calendar is the worked reference profile with JSON, an agent skill and a Core fixture suite. Operator has an initial draft contract, skill, Core and optional-facet fixtures, plus a Ghostlight-derived Vendor example; neither has independent passing implementations yet.
- The reference runner, wrapper and playground are specified but unbuilt. Commands such as shiguchi test and shiguchi wrap describe the intended product boundary, not a tool someone can install today.
- Most catalog classes remain pre-fixture sketches. The standing rule is to prove the runner and validation slice before growing the profile catalog further.
What it actually does
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.
The concept
What's inside
What it is
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.
The concept
What it is
A paced-breathing companion built to be held rather than watched. A tuned, runnable prototype exists today; the shippable app does not yet.