Single Process Fabric
A single-process topology runs the fabric, node, client code, and one or more agents in the same process.
It’s the best way to learn Naylence’s core primitives with the fewest moving parts: no sentinel, no admission URLs, no networking.
Shape
What you build
In practice, a single-process “hello” usually looks like:
- Create a local fabric.
- Register/serve an agent on an address.
- Send a message to that address.
- Print the result (and optionally stream updates).
This is exactly what the Getting started quickstarts do.
When to use
Use this topology when you want:
- a minimal “Hello, Naylence” that proves your setup works,
- a tight feedback loop while you learn the API,
- unit/integration tests that don’t require networking,
- to prototype agent behavior before worrying about deployment shape.
When not to use
Avoid (or quickly graduate from) single-process when you need:
- a trust boundary (public client vs private agents),
- centralized admission/routing policy,
- separate scaling of work vs control,
- runtime separation (browser ↔ backend, Python ↔ TypeScript),
- isolation from crashy/experimental agents.
Single-process is a learning/prototyping topology — it proves the primitives. As soon as you care about boundaries, you’ll usually introduce a sentinel.
Notes
- Clients aren’t second-class. Even in single-process, the “client” side can listen and handle streaming. The difference is role (who initiates vs who serves), not capability.
- Multiple agents are fine. You can register multiple addresses and have agents call each other without changing topology.
- This is still a real fabric. Most of the code you write here carries forward unchanged when you later split across nodes.
Next step
If you want the smallest “real deployment” upgrade, move to a topology with a sentinel at the edge:
That introduces admission + routing while keeping the overall system small.