Structure matters, but structure alone is not the breakthrough.
Any system can store facts. Plenty of systems can organize them into tables, graphs, or embeddings. The harder question is whether that structure helps the agent surface the right context at the right moment, and keep unhelpful context from lingering forever.
Signet’s knowledge architecture is built around one question:
What is the minimum amount of knowledge the agent needs to act correctly right now?
Everything else — how facts are stored, how they’re connected, how the database evolves over time — is in service of answering that question as efficiently as possible.
The North Star
When you say “please update my website with my new email,” the agent should already know where the website lives and what the new email is. It answers “sure, one moment” and does it.
That moment — frictionless, informed action — is what the entire knowledge architecture exists to produce. Knowledge exists to collapse the distance between a request and useful action.
How Knowledge Gets Refined
Knowledge doesn’t arrive structured. It arrives messy.
A session produces hundreds of observations. A document produces thousands of sentences. The agent encounters facts in passing, half-formed, buried in context. None of it is immediately useful in the form it arrives.
The extraction Pipeline is the refinery. It runs outside the conversation — the agent is never involved. No memory tools, no “remember this” commands. The distillation engine reviews sessions after they end, and over time, continuously and in the background, it takes raw material and distills it:
sparse facts
↓
observational facts
↓
atomic facts ←—— the target form
↓
procedural memorySparse facts are the raw input — unprocessed, high volume, low signal. Things the agent heard or saw but hasn’t evaluated yet.
Observational facts are extracted and validated, but not yet grounded. The agent knows them, but they haven’t been connected to anything yet.
Atomic facts are the goal. A well-formed atomic fact stands alone. It names what it’s about, captures the relationship, and carries enough context to be useful in isolation — without the session that produced it, without the document it came from.
Procedural memory is knowledge about how to do things. Workflows, rules, repeatable processes. These live slightly differently from facts — they’re closer to skills than statements.
The pipeline never stops running. It processes asynchronously, in the background, while the agent is idle or active.
The result: a database that gets smaller and smarter over time, not larger and noisier.
A heavy week of sessions might balloon the database to 7,000 memories. Leave it alone for two weeks. Come back to find 1,000 — but those 1,000 are dense, properly connected, constraint-aware, and organized around the things that actually matter. The noise has been refined away. What remains is structure.
Everything Is Either an Entity, or It Belongs to One
This is the core organizing principle of Signet’s knowledge graph.
An entity is anything that can be identified — a person, a project, a system, a tool, a concept. Entities are persistent. They accumulate knowledge over time. They never expire. They are the organizing scope of the entire knowledge graph.
nicholai is an entity. ooIDE is an entity. WorkOS is an entity. Their relationships to each other — that nicholai works on ooIDE, that ooIDE uses WorkOS for auth — are not separate facts floating loose in the database. They are properties of those entities, organized under the dimensions that make them intelligible.
Entity weight reflects how central an entity is to your world. It’s partly structural — an entity with twelve aspects and forty attributes is more important than one with two — and partly learned, built from how often the entity appears in sessions and how useful its knowledge proves to be. Both signals matter. Frequency is real signal. But frequency alone misses context: some entities are universally important, others only matter for certain kinds of work.
Aspects, Attributes, and Constraints
If entities are the what, aspects are the what you need to know about it.
An aspect is a named dimension of an entity. ooIDE has an auth aspect, a build pipeline aspect, a data model aspect. nicholai has a technical preferences aspect, a decision-making aspect. Aspects don’t store facts — they organize them.
Attributes are the facts organized under aspects. “ooIDE uses WorkOS for auth” is an attribute of the auth aspect of ooIDE. “Bun is the package manager” is an attribute of the build pipeline aspect. Attributes are atomic facts. They have a home.
Constraints are attributes that are non-negotiable. They gate action regardless of anything else. “Never push directly to main” is a constraint on ooIDE’s development aspect. When the agent is about to do anything involving ooIDE’s codebase, that constraint surfaces — not because it ranked highly in a similarity search, but because constraints always surface. That’s the rule.
Here’s what this looks like in practice:
entity: ooIDE
├── aspect: auth system
│ ├── attribute: uses WorkOS for authentication
│ ├── attribute: WorkOS dashboard at [url]
│ └── constraint: never store auth tokens in client code
├── aspect: build pipeline
│ ├── attribute: bun is the package manager
│ ├── attribute: `bun run dev` starts frontend and backend
│ └── constraint: run typecheck before committing
└── aspect: team
├── attribute: nicholai is the primary developer
└── dependency → nicholai [entity]The dependency on nicholai is not a semantic link inferred from word similarity. It is an explicit structural edge. When reasoning about ooIDE, the agent can follow that edge and make nicholai’s relevant aspects available. This is one of the ways the graph helps shape a bounded candidate pool before flatter retrieval layers or learned ranking take over.
Tasks Are Not Entities
Tasks behave like entities in structure but not in lifecycle.
A task can have aspects, dependencies, and relationships. “Deploy the new auth flow” can depend on the ooIDE entity, reference the auth aspect, and require nicholai’s approval. The structural vocabulary is the same.
But tasks are built to expire. They complete, they get cancelled, they age out. They don’t accumulate weight over time. When a task is done, it’s done — it gets retained briefly for context, then released.
Conflating tasks and entities would mean completed work accumulating importance scores forever, cluttering the graph with finished things. Entities grow. Tasks close.
The goal of this architecture is not to build the most complete knowledge graph. It is to build the most useful substrate for context selection.
A database full of atomic facts, organized under entities, structured by aspects, connected through explicit dependencies, with constraints that always surface, gives the system a much better starting point than a flat pile of transcripts. The structure does real work. But it is still substrate. The point is not “we have a graph.” The point is that the graph makes it easier to build a bounded, coherent set of candidates that the system can rank, trim, and learn over time. For technical implementation details, see the knowledge architecture docs.
Constraint Confidence
Constraints don’t just gate action — they tell the agent how much it knows about an entity.
An entity with a rich constraint set is one the agent understands well. It knows what’s allowed, what’s forbidden, what requires care. It can move confidently. An entity with no constraints is one the agent has barely met — it should slow down, assume less, and verify more.
This is an internal signal, not a user-facing one. The agent uses constraint density to calibrate how autonomously it acts on a given entity. The user never manages it, configures it, or even sees it directly. It’s just behavior: the agent is more cautious around unfamiliar entities, more decisive around well-mapped ones.
In the constellation view, this manifests as node brightness. Entities with dense constraint graphs are luminous. New entities are dim. The visual tells you, at a glance, where the agent is operating on solid ground.
Context Is Bounded by Design
One of the structural advantages of this architecture is that context loading can start from something deterministic.
When the agent identifies which entities are active in a session, it can load their graphs: aspects, attributes, constraints, and first-degree dependencies. The cost is known before it starts. The result is bounded. That gives the system a coherent starting pool before it consults flatter retrieval layers or learned ranking.
This is the practical case for the entity graph over pure embedding search. Embedding search scales with database size. It’s probabilistic. It can miss structurally critical facts that don’t happen to sound similar to the query. The graph walk can surface what is structurally required before semantic similarity is asked to do all the work by itself.
Embedding search still has a role — it’s how the agent discovers things the graph hasn’t connected yet. The graph walk loads known structure. Search fills the gaps. Learned ranking is what decides which of those candidates should actually earn scarce context window space.
Constraints Evolve Without Your Help
Constraints are the most stable part of the knowledge graph, but they aren’t frozen.
The system observes how constraints interact with reality over time. If a constraint is consistently relevant — the agent encounters it, respects it, acts accordingly — it stays exactly as it is. If a constraint is consistently contradicted by the user’s actual behavior, its effective weight decays. Not to zero. Constraints have a floor. But a constraint that no longer reflects how someone actually works gradually loses the urgency it once had.
The user doesn’t manage this. There are no review prompts, no “this constraint hasn’t been used in 30 days” notifications, no settings panel for constraint lifecycle. The system observes. The system adapts. If the user says something that explicitly supersedes a constraint, the agent updates it in the moment — as a natural part of the conversation, not as a maintenance task.
This is the broader principle: the memory system is set and forget. The user’s job is to work. The system’s job is to remember, organize, and get out of the way.
The Graph Shapes the Candidate Pool
We call this concept desire paths — like the worn trails in a park that reveal where people actually walk, the knowledge graph learns which traversals are productive and reinforces them over time. But the real shift is not from search to traversal. It is from naive retrieval to context selection.
Current memory systems find relevant knowledge by asking: what is semantically similar to this query? They embed the query, embed the memories, compute cosine distances, retrieve the closest matches. This works. It’s also expensive, probabilistic, and structurally blind — it finds things that sound related, not things that are structurally required.
In Signet’s knowledge architecture, session-start can ask a different question: what entity is this session about? Walk its aspects. Pull its attributes and constraints. Follow its dependencies. You now have a bounded, structured context candidate set before an embedding call, before a vector search has to shoulder the whole problem, before thousands of unrelated memories get considered.
Signet’s predictive scorer runs on top of this. The structure gives it something coherent to learn over: which aspects matter most for which kinds of sessions, which attributes to prioritize, which dependencies are worth following, and which retrieved context keeps showing up without actually helping. The goal is for the system to learn from regret, not just reuse, so stale or distracting context gradually loses influence instead of haunting the window forever.
The floor is better. The ceiling is higher. For the deterministic guarantees that protect knowledge during distillation, see Lossless Context Patterns.
What You’ll See
As this architecture rolls out, users will see something unusual: their databases shrinking.
Not because memories are being deleted — because they’re being distilled. 7,000 sparse facts become 1,000 atomic facts, properly organized, back-linked, constraint-aware. The noise compresses away. The signal remains.
And in the constellation view, the structure becomes visible. Instead of clouds of semantically similar memories, you’ll see entities with distinct shape — aspects radiating out, attributes attached to those aspects, dependencies connecting entities to each other. The actual relationships between things, not just their semantic proximity.
The difference between a person and an aspect of a person. Between an attribute and a constraint. Between something that matters always and something that matters right now.
Small. Dense. Connected. Correct.
Written by Nicholai and Mr. Claude, the first Signet agent. Structured relationships, constraints methodology, and entity/aspect/attribute framework co-developed with Micheal Luigi Pacitto (PatchyToes). March 3, 2026.
