A company approves a new decision. The document changes. An employee's saved plan does not.
Which work now needs review? Which teams are affected? Who can help?
Workweave is an employee workspace built for the Company Brain track of Graph Hacks. Its agent uses FalkorDB to answer these questions from relationships between work, decisions, sources and people.
Source code · Hosted workspace · Graph model and setup
A decision is more than a recent document
The sample story follows three people. Maya is an engineer. Priya approves company decisions. Leo reviews Maya's work.
Maya saved a checkout plan based on Adyen. Priya later approves Razorpay as its replacement. Workweave keeps Maya's original plan and marks it for review. It does not silently rewrite her notes.
A later proposal is not automatically an approved decision. The graph checks approval, service scope, replacement links and source support. Missing or conflicting authority blocks affected actions.
These are synthetic company records. The provider names do not represent real company decisions or live integrations.
What the graph stores
FalkorDB stores the operational context, including assignments, services, decisions, source documents, reviewers and saved plans.
Maya → ASSIGNED_TO → Assignment → TOUCHES → Service
Leo → REVIEWER_FOR → Service
Decision → APPLIES_TO → Service
Decision → SUPPORTED_BY → Document
New decision → SUPERSEDES → Earlier decision
Saved plan → SUPPORTED_BY → Decision
Work item → TOUCHES → Service → DEPENDS_ON → Service
The saved plan retains the decision it used. That identity lets the application detect a replacement without comparing document wording.
The README graph diagrams show the model. The Cypher catalogue contains the queries used by the application.
An agent with checked output
Maya asks:
What changed for my work, who else is affected, and whom should I ask?
The model chooses from four read-only tools:
-
get_current_decision: check approved guidance and its source. -
inspect_saved_plan: compare the saved plan with current guidance. -
find_affected_work: follow service dependencies and find linked owners. -
find_reviewers: find the people recorded as reviewers for this work.
The model selects observed fact IDs and proposes next steps. The server builds factual text from the checked graph records. It rejects unknown fact IDs, missing authority checks and changed evidence.
The agent cannot approve decisions, save a plan or send messages. Maya makes those changes through explicit actions. This is a constrained tool-planning agent, not unrestricted generated advice.
The assistant opens beside the task. Maya can keep her work visible while she asks a question.
The test: change a relationship, keep the text
The strongest test changes one dependency instead of changing a document.
Before the change, Support has two routes to Checkout:
Support → Checkout
Support → Billing → Checkout
Billing also depends on Checkout. The application finds four affected work items.
Next, the demo removes Billing → Checkout. Billing's task must leave the result. Support must remain, because its direct route still exists.
| Evidence | Before removal | After removal |
|---|---|---|
| Affected work items | 4 | 3 |
| Billing task BILL-204 | Included | Excluded |
| Support task SUP-310 | Included, two routes | Included, one route |
| Source content | Same content hash | Same content hash |
The same question was sent to the configured OpenAI agent before and after this change. Both live answers identified the stale plan and reviewers. The second answer removed Billing and retained Support with one route. Neither run changed Maya's saved plan.
The recorded live result contains the facts, completed tool names and checks. This is two runs on one synthetic scenario, not a general accuracy benchmark.
How FalkorDB finds the paths
Dependency retrieval uses a bounded, directed Cypher traversal. This fragment shows the core path query:
MATCH (w:WorkItem)-[:TOUCHES]->(s:Service)
MATCH p=(s)-[:DEPENDS_ON*0..5]->(root:Service {id:$root})
WHERE all(node IN nodes(p)
WHERE single(other IN nodes(p) WHERE other=node))
RETURN w.id, w.title, [node IN nodes(p) | node.title]
ORDER BY w.id
The full query also retrieves team and owner links. Results are grouped by source ID so alternate routes do not duplicate work items.
For indirect dependencies, native algo.SPpaths supplies a verified shortest explanation. The bounded traversal retains the alternate routes; a single shortest path alone would not establish that all routes disappeared.
Another database could implement this logic. The point of the test is that FalkorDB relationships control this application's answer. The graph is not a picture added after retrieval.
Design lessons
Approval and freshness are different. Newer text can be an unapproved proposal. Approval must be represented and checked.
Acknowledgement and acceptance are different. Reading a replacement does not mean that an old plan has been updated. Workweave records both actions separately.
One broken route does not remove all impact. Alternate routes matter. The removal test checks retained work as well as removed work.
More context does not guarantee a correct model answer. An earlier paired model diagnostic still produced abstention and citation failures with graph context. That result led to checked fact IDs and server-side action gates. The validation report includes those failures and the method's limits.
What remains
The prototype uses normalized synthetic exports, not live Jira, Calendar or Zoom synchronization. Missing links can hide affected work. Traversals stop after five links. A visitor cookie isolates sample graphs; it is not production employee authentication.
Production work would need identity, permission-aware retrieval, reliable connector updates and operational monitoring. Agent access also needs provider spending controls; an operation limit is not a dollar cap.
Workweave's useful result is a checked connection between a changed decision and the work that depends on it. The employee can inspect the source and choose the next action.
AI disclosure: Codex assisted with implementation, tests, documentation and this article draft. Automated checks are documented separately from participant review. No independent user test or production accuracy claim is made.
