AI Context Graphs: Connect Facts, Decisions, and Work

An AI context graph connects records, such as documents, decisions, tasks, and people, through named relationships that an assistant can follow. It helps answer questions like “Which approved decision explains this task?” rather than merely finding text containing the same words.

Tools like fenbs provide an explicit shared work record for projects, decisions, and progress. That can solve a team’s continuity problem without automatically building a graph of everything it knows. Start with the relationships your work needs before choosing a more elaborate system.

What are the parts of a context graph?

A node represents something you want to identify: a task, a document version, a project, or a decision. An edge represents a relationship between two nodes. Labels give the relationship meaning, such as “implements,” “replaces,” or “supported by.”

The W3C RDF primer↗ (opens in a new tab) explains a formal graph model built from statements about a subject, a relationship, and an object. A product using the phrase context graph does not necessarily use RDF, the Resource Description Framework. Ask how that particular product represents and retrieves connections.

Identity matters as much as a label. Two records named “contact form” may describe different releases or clients. Give important records stable references and enough scope that an assistant can distinguish them. Otherwise, a neat connection can point to the wrong work.

How does a connected record help an assistant answer?

Suppose you ask why the website collects fewer fields. A search may find several drafts discussing forms. A useful connected record points from the implemented task to the approved decision, then to the reviewed source behind that decision.

The assistant can use that path to assemble a focused answer with evidence. It still needs access to the records and a way to retrieve their contents. A graph stored somewhere the assistant cannot query does not enter the conversation by itself.

The retrieved information also needs to fit the AI context window, the model’s working space for a response. A graph can help select relevant records; it does not give the model unlimited working capacity or guarantee that the selected evidence is sufficient.

Which relationships are worth recording first?

Choose relationships that change what someone does next. “Task implements approved decision” is useful when a designer asks whether a requirement can change. “Two files mention blue” may be less useful unless color is part of the actual question.

• Decision to evidence: where the reason can be checked.
• Task to decision: which approved choice the work carries out.
• New decision to old decision: what was replaced and what remains valid.
• Task to verification: what was checked and what still needs checking.
• Project to handoff: where the next session should begin.

Keep the vocabulary small. If one teammate writes “depends on” to mean technical dependency and another means “awaiting approval,” an assistant may follow the connection correctly but interpret it incorrectly. Define the relationship or use more specific wording.

A small project can express these connections in ordinary written records with references. Our guide to AI context files covers file-based approaches. You do not need a graph database just to explain why a task exists.

How do you prevent connected guesses from becoming facts?

Store the source and status of important statements. A model’s inferred connection, a draft suggestion, and a person’s approved decision should remain distinguishable. Connecting a claim to several other claims does not make it true.

The W3C provenance overview↗ (opens in a new tab) describes information about the entities, activities, and people involved in producing something. In your work record, the practical questions are simple: who asserted this, what supports it, and has it been reviewed or replaced?

Say an assistant infers that a launch moved because a security review is incomplete. Record that as a hypothesis until someone confirms it. If the real reason was a client scheduling change, correct the relationship and its downstream explanation rather than leaving both accounts looking authoritative.

Access needs equal care. A visible task should not reveal restricted source text through a linked answer. Retrieved content can also contain misleading instructions; OWASP’s prompt injection guidance↗ (opens in a new tab) explains that risk. A source is evidence to evaluate, not automatic permission to act.

When is a graph more work than you need?

Use a simple project record when people mainly ask what was agreed, what is in progress, and where to continue. Consider a dedicated graph implementation when important questions repeatedly require following several typed relationships across a large collection of records.

Before adding that complexity, try answering a few real questions manually. Note which connections were missing and whether a clear reference would have solved the problem. If nobody can name a question the graph improves, the maintenance burden may arrive before the benefit.

Long-term memory organization is a nearby topic covered in AI memory graphs. Here the focus is the connected evidence and work needed for a particular answer.

fenbs keeps tasks, Decisions and rules, and Where we left off together as a shared project record. It does not automatically infer a context graph or replace a graph database you need to build into your own application.

How to do this with fenbs

1. Create a free account, free for one person with no credit card, and add one active project.
2. Add the tasks that represent the current work. Keep each task’s problem, plan, and test result clear.
3. Record person-approved decisions and standing rules in Decisions and rules, linking the tasks they affect.
4. Connect a supported AI app using Integrations, then ask it to read the project context before proposing its next action.
5. Save Where we left off with the remaining questions and next step. Correct uncertain findings before later sessions rely on them.

fenbs is not the right fit if you need automatic entity extraction, custom graph queries, or an application-level graph engine. It fits the narrower job of keeping shared work explicit and reviewable across supported assistants.

How do you keep the connections current?

Review the connections when a task changes, a decision is replaced, or a source is revised. Preserve the distinction between historical truth and current guidance. An old approval may explain a past release while being wrong for the next one.

Ask the next assistant to show the evidence path for an important answer. A missing source or ambiguous relationship is a maintenance signal. The guide to AI context rot explains how stale information undermines useful context; the context engineering hub connects the wider set of practices.