A delivery date changed. Which promises now need attention?
In the fictional Harbor Supply workspace, a supplier's arrival moves to October 23. Acme needs 10 cartons by October 19, with only 2 unallocated units available. Beacon needs 8 by October 20, with none available.
Workweave follows the recorded dependencies, flags those two commitments for review, finds the responsible team, and creates two internal review tasks. It also explains why two other checked orders do not need review. Later, when the Beacon task is marked done, that outcome stays in memory next to the original findings.
That is the workflow I wanted to build: follow a change, explain what it affects, record the next step, and remember the outcome.
Workweave is a company knowledge and work assistant powered by FalkorDB. Teams upload their own documents, ask questions with sources, and review work suggestions against confirmed responsibilities. Logistics is the clearest demo; fictional energy, food production, and software packs test the knowledge features.
Try the app · Source code · Watch the 3:50 demo
Tracks: Company Brain · Agent Memory and Coordination · Agents That Act on Connected Data.
Status: the demo shows graph investigations, persistent memory, and source-backed answers. The backend passed 57 tests against real FalkorDB, including integration tests with simulated Slack and ClickUp responses. Live Slack-to-ClickUp dispatch is not demonstrated.
What I built, and when
I started building Workweave on October 15, 2026, the opening day of Graph Hacks.
During the event (October 15–18), I built:
- The company knowledge foundation: document imports, versioned evidence, source-backed answers, graph investigations, internal review tasks, and persistent memory.
- The Slack → ClickUp workflow: signed Slack events saved before acknowledgement, a Task Inbox, and human-approved task creation.
- Graph-based assignee matching: candidates come from FalkorDB paths, not from a model's guess.
- Durable delivery and recovery: leases, reconciliation before creating a task, and tests for lost responses and competing workers.
- Onboarding and settings, an Ollama Cloud adapter, and a production deployment on Fly.
- The test suite, demo video, and documentation.
The repository includes my build and AI-assistance disclosure.
Why searching documents is not enough
A search can find the supplier's revised arrival date. It still leaves the team to connect that date to purchase orders, customer commitments, available stock, and the people responsible.
Workweave stores those supported relationships in FalkorDB. A traversal finds orders connected to the changed record and returns the paths. Application checks then compare dates and quantities. Search still handles company questions and source passages; graph traversal handles questions that depend on connections across records.
In this example, two orders share the dependency but do not need review because their dates or stock cover them. Being connected is a reason to check, not proof of a problem.
What breaks without FalkorDB
Take FalkorDB away and the product stops working. Retrieval, dependency traversal, assignment paths, conversations, persisted jobs, and memory all live in the graph. There is no alternate business database that keeps these workflows running.
Each company has its own knowledge graph. Backend membership checks control which graph a user can access, with additional ownership checks for private conversations.
The delivery example in detail
Workweave follows the purchase order's dependencies and checks the actual commitments:
| Commitment | Result | Why |
|---|---|---|
| SO1 · Acme cartons | Needs review | Required before the new arrival; stock is insufficient |
| SO2 · Beacon cartons | Needs review | Required before the new arrival; no unallocated stock available |
| SO3 · Later cartons | Excluded | Required after the new arrival |
| SO4 · Tape with stock | Excluded | Unallocated stock covers the order |
| SO5 · Unrelated tools | Not assessed | Outside this purchase order's dependency paths |
The Cypher behind it
The application resolves the requested record against current source evidence, then binds its ID to $id:
MATCH path=(o:Entity {entity_type:'SalesOrder',active:true})
-[:DEPENDS_ON*1..4]->(target:Entity {id:$id,active:true})
WHERE all(n IN nodes(path) WHERE n.active=true)
MATCH (o)-[:DEPENDS_ON]->(po:Entity {entity_type:'PurchaseOrder',active:true})
OPTIONAL MATCH (o)-[:DEPENDS_ON]->(product:Entity {entity_type:'Product',active:true})
RETURN DISTINCT o.payload AS order_json, po.payload AS po_json,
product.payload AS product_json,
[n IN nodes(path) | n.id] AS path_ids
ORDER BY o.required_date
In plain English: find active sales orders that depend on the changed record through one to four recorded connections, and return the path IDs so the interface can show why each order is connected. The query finds candidates. Python then checks source versions, dates, quantities, and unallocated stock.
From a changed date to a remembered outcome
After someone marks the Beacon review task done, the memory page shows Beacon as done and Acme as open, next to the original findings, source buttons, and the current procedure. The next session picks up from that recorded outcome.
These screenshots come from the synthetic Harbor Supply demo, where the investigation is deterministic and uses the implemented graph tools. Marking a review task done records a user update; it does not prove a delivery arrived or a customer was contacted. These internal tasks are separate from ClickUp tasks.
Company knowledge: upload, confirm, ask
A new user picks a work area and a workspace name, then uploads a company profile, procedure, report, or supported spreadsheet. Workweave shows a preview before saving anything as company knowledge.
People and responsibilities found in documents are suggestions. An administrator confirms them before the app relies on them. For example, a guide might say that Ada handles billing issues; the administrator confirms the role and links Ada to her ClickUp user in Team Roster.
When someone asks, "Who handles billing issues, and what is our approval process?", Workweave retrieves current evidence and writes an answer with source buttons that open the original passage. If the documents don't contain the answer, the app says so. Source versions are kept, and old or withdrawn evidence is filtered out of current answers.
From a Slack message to an approved ClickUp task
An administrator connects a Slack app using its bot token and Signing Secret, entered privately in Connections. They add Workweave's public HTTPS callback to Slack Event Subscriptions, grant the required scopes, invite the bot, and select the channels to watch. Selecting no channels monitors none.
When Slack sends a message, Workweave verifies the signature and workspace, then saves the event in the company's FalkorDB graph before acknowledging it. Slower AI work happens afterward, and a saved event can be resumed after an interruption.
The AI decides whether the message asks for work. A greeting should not become a task. For a real request it drafts a title, description, matching terms, and any deadline, but it has no permission to create anything yet.
Finding the right person
FalkorDB first finds active, confirmed people whose recorded responsibilities match the request and who have a ClickUp user mapping:
MATCH path=(person:Person)-[:HAS_ROLE]->(role:Role)
-[:RESPONSIBLE_FOR]->(responsibility:Responsibility)
WHERE person.active=true AND person.confirmed=true AND person.clickup_id <> ''
AND any(term IN $terms
WHERE toLower(role.name + ' ' + responsibility.text) CONTAINS term)
OPTIONAL MATCH (task:ExternalTask)-[:ASSIGNED_TO]->(person)
RETURN person.payload AS person, [n IN nodes(path) | n.id] AS path_ids,
collect(task.payload) AS tasks
LIMIT 200
Python scores the results by responsibility overlap, similar tasks finished on time, tasks that ran late or were reassigned, and current workload. Attached document evidence must still be current. Confirmed manual roles are also supported and are not presented as document-derived facts. The AI may review the top three candidates and choose only among their supplied IDs; the administrator can inspect and change that suggestion.
Human approval, then ClickUp
ClickUp is connected separately using a personal API token and the numeric destination List ID. Eligible team members are mapped to their ClickUp user IDs in Team Roster.
Slack request → AI drafts → FalkorDB finds people and paths
→ administrator reviews and approves → worker creates the ClickUp task
→ task ID, confirmation and outcome are saved
The proposed task appears in the Task Inbox with the original message, the draft, candidates, matching factors, and evidence. Only Approve & Create in ClickUp sends it. A model saying "create this task" is never enough.
When the response never arrives
A timeout does not always mean failure. ClickUp could create a task, then the connection could drop before Workweave gets the ID, and a naive retry would create a duplicate.
So the worker records that creation has started before sending the request, and each job carries a stable marker in the task description. On retry it searches for that marker and saves the existing task ID if it finds one. An unsuccessful search is not treated as proof the task is absent, and an uncertain earlier attempt pauses for review instead of blindly recreating.
The regression test reproduces this: the simulated ClickUp stores the task, then times out. On the next attempt the search finds it. The test asserts only one create request and that the job finished with its assignment intact. It runs against a real FalkorDB with simulated external HTTP responses.
Read the lost-response and competing-worker tests
What the app remembers
Conversations, investigations, internal tasks, approved procedures, and recorded outcomes live in the company's graph, so a user can return later and see what was found and what happened next. The ClickUp worker periodically checks task updates, and those outcomes can inform later assignment suggestions. This is the app reading saved context, not training a model on every message.
Architecture
- Next.js and React: the interface.
- FastAPI: sign-in, access checks, imports, questions, and integration endpoints.
- FalkorDB: company facts, relationships, conversations, tasks, job state, and memory.
- Configured AI providers: extract proposed work and help write source-grounded answers.
- Background workers: process requests and deliver approved external actions.
- Encrypted backend vault: holds credentials separately from company knowledge.
Architecture and source-file map · Graph model · Cypher catalogue
What has been tested
The backend suite passed 57 tests in Linux against a disposable real FalkorDB. Slack and ClickUp responses were controlled. The tests cover the full request, assignment, approval, creation, and confirmation flow, plus competing workers, lost responses, stale sources, permissions, and recovery. The frontend production build and TypeScript check passed.
The repository includes four fictional company packs and a reviewer guide with 24 questions and a separate answer key. Upload the company documents, not the answer key, and use a separate workspace for each company.
Honest limits
- In the video, Slack authentication succeeded but channel permissions were still pending, and ClickUp is shown at setup only. No live Slack-to-ClickUp dispatch is claimed.
- The delivery investigation is deterministic and runs on synthetic Harbor Supply data. Other industries need structured data and supported relationships.
- Dependency tracing is bounded to four hops.
- Assignee matching is a practical scoring rule, and administrators can inspect and change it.
- High-concurrency, multi-agent operation has not been benchmarked.
- The recovery logic reduces duplicate writes; it is not an exactly-once guarantee from external APIs.
What I learned
Finding a connected record is only the first step. In the delivery example the graph finds candidate orders, but dates and stock decide whether they need attention, and returning the path makes that decision easy to inspect.
A timeout is not proof of failure. Saving a job before processing it, recording external task IDs, and checking uncertain results are part of making an action reliable.
Connecting an account is also different from having permission to read its data. Slack authentication worked, but channel discovery needed more scopes, so the demo labels that setup as pending.
Tracks and AI disclosure
Company Brain: company knowledge, people and responsibilities, and source-backed answers. Agent Memory and Coordination: saved outcomes, checkpoints, and the investigator-to-coordinator handoff. Agents That Act on Connected Data: graph investigations that identify affected commitments, resolve owners, and create internal review tasks.
OpenAI Codex and GitHub Copilot assisted with development; Codex also helped with testing, deployment, documentation, and demo preparation. I directed the product, designed the company scenarios, and reviewed the results. I reviewed and tested the implementation and can explain its architecture, graph model, and technical decisions. The video uses synthetic narration.
Top comments (0)