Workweave: an AI company brain that turns information into useful work

A developer built Workweave, an open-source "company brain" that uses FalkorDB's graph database to connect company documents, spreadsheets, and Slack messages into a single knowledge system. The tool answers questions with cited source passages, suggests people and responsibilities for administrator review, and converts Slack work requests into draft tasks while filtering out stale evidence. Slack events are validated by signature and persisted to the graph before acknowledgment, keeping slower AI processing out of the initial response.

Most companies already have useful information. Some is in documents, some is in spreadsheets, and some is in Slack messages. The hard part is connecting it. Someone asks a question. A manager looks for the right document. Another person checks who owns the work. Someone else creates a task. Later, the team has to remember why that task was created and what happened to it. I built Workweave to bring these steps together. Workweave helps teams ask questions about their company, check the source behind an answer, find the people responsible, and keep a record of the next step and its outcome. It uses FalkorDB to store the information and the connections between it. It is designed for company knowledge across industries. Logistics is one example in the demo. The repository also includes fictional energy, food production, and software companies. Try Workweave https://workweave-web.fly.dev · Source code https://github.com/Haleem-code/Workweave · Watch the 3:50 demo https://youtu.be/3Rfimah TUQ A new user chooses the company's work area, what they want help with, and a workspace name. These choices help the app show useful starting guidance. The user can then upload a company profile, a procedure, a report, or a supported spreadsheet. Workweave shows a preview before saving the information as company knowledge. People and responsibilities found in documents are suggestions. An administrator reviews them before relying on them. A person mentioned in a document does not automatically get an account or permission to use the app. For example, a company guide might say that Ada handles billing issues. The administrator can confirm that role and connect Ada to her ClickUp user account in Team Roster . A user might ask: Who handles billing issues, and what is our approval process? Workweave looks through the company's current information, finds relevant evidence, and uses that evidence to prepare an answer. The user can open a source button to check the original passage. If the documents do not contain the answer, the app should say so. For example, knowing the Managing Director's name does not tell us who founded the company. Documents can change. Workweave keeps source versions and filters out old or withdrawn evidence when preparing current answers. An administrator connects a Slack app using its bot token and Signing Secret. These are entered privately in Connections , not added to GitHub. Workweave gives the administrator a public HTTPS address for Slack events. They add it to Slack's Event Subscriptions, give the app the required permissions, invite the bot, and choose which channels Workweave should watch. Only selected channels are used. Selecting no channels means no messages are monitored. When Slack sends a message, Workweave checks that it came from the configured app/workspace and has a valid signature. It saves the accepted event in the company's FalkorDB graph before acknowledging it. Reading the author's name and asking the AI to review the message happen afterward. This keeps slower AI work out of the first response to Slack. It also gives the app a saved event to continue processing after an interruption. Imagine someone posts this in a selected company channel: Please fix the billing export. The invoice totals are wrong. The AI checks whether the message asks for work. A greeting or a thank-you message should not become a task. For a work request, the AI prepares a draft title, description, useful matching words, and any deadline mentioned in the message. It does not get permission to create an external task at this stage. If AI extraction is unavailable, the app can leave the request for manual review instead of pretending that the AI completed the decision. The AI does not choose from a list of random names. Workweave first asks FalkorDB for suitable people based on the company's confirmed information. The graph stores connections such as: Person → Role → Responsibility Past task → Assigned person Person → Supporting document For the billing example, a confirmed person responsible for billing exports is a better match than someone whose role is warehouse dispatch. The app considers: People must be active, confirmed, and mapped to a ClickUp user before they can be automatic assignment candidates. Attached document evidence must still be current. FalkorDB finds the connected records and returns real graph paths. Application code calculates a clear fit score from those results. When available, the AI can review the top three candidates and choose only from those supplied people. It cannot invent a new employee. This is a practical matching rule, not a promise that the AI always knows the best person. The administrator can inspect the reasons and change the choice. ClickUp is connected separately using a personal API token and a destination List ID . The List ID tells Workweave where approved tasks should go. The proposed task first appears in Task Inbox . The administrator can review: The administrator can edit the draft or change the assignee. Only after they choose Approve & Create in ClickUp does the worker send the task to ClickUp. Once creation is confirmed, Workweave saves the task ID and tries to post a confirmation in the Slack thread with a link to the task. Slack request ↓ AI prepares a draft ↓ FalkorDB finds suitable people and their supporting connections ↓ Administrator reviews and approves ↓ Worker creates the ClickUp task ↓ Task ID, confirmation and later outcome are saved The app does not create ClickUp tasks or send confirmation replies just because an AI model said to do so. Human approval is the gate. A network problem should not create the same task twice. Each approved job has a stable ID and a marker that can be found in ClickUp. Before creating a task, the worker checks whether that task already exists. If ClickUp may have accepted the task but its reply was lost, Workweave searches for the existing task. It does not blindly send another create request. If the result is still unclear, it pauses for review. Slack confirmation is tracked separately. A failed Slack reply does not erase the ClickUp task or falsely mark the entire job complete. These checks make recovery safer. They do not mean three separate services share one perfect, exactly-once transaction. Workweave keeps conversations, investigations, internal tasks, approved procedures, and recorded outcomes in the company's graph. A user can return later and see what was found and what happened next. The ClickUp worker also periodically checks task updates. Those recorded outcomes can help with later assignment suggestions. This is the app reading saved context, not training a new AI model on every message. Company workspaces have separate knowledge graphs. Access checks also control which company and private conversation a user can read. The delivery example makes the relationships easy to see. A supplier shipment changes date. Workweave follows the connected purchase order to customer commitments, then checks deadlines and stock. Two orders need attention. Two other connected orders are excluded for clear reasons. An unrelated order is outside the investigation's paths. This is one implemented operational workflow. Company document questions and role-based task routing are broader features. Deeper checks for other industries need the right structured data and supported relationships; choosing an industry during onboarding does not create all those rules automatically. See the architecture diagrams and source-file map https://github.com/Haleem-code/Workweave/blob/main/docs/architecture.md . The complete backend suite passed 57 tests in Linux using a real disposable FalkorDB database. Tests used controlled Slack and ClickUp responses to check the full request, assignment, approval, creation and confirmation flow. They also tested competing workers, lost responses, stale sources, permissions and recovery. The frontend production build and TypeScript check passed. In the public video, Slack authentication succeeded for KoraBridge, but channel permissions were still pending. ClickUp is shown at setup. The recording therefore does not claim a completed live Slack-to-ClickUp dispatch. The repository includes four fictional company packs and a separate reviewer question guide. Reviewers should upload the company documents, not the answer key, and use a separate workspace for each company. Building Workweave taught me that finding information and deciding what to do are different problems. Graph relationships help explain who owns work and why they are a suitable match. I also learned to save incoming events before slow AI processing, require human approval before external actions, and handle uncertain API responses without blindly creating duplicate tasks. The named tracks are Company Brain , Agent Memory and Coordination , and Agents That Act on Connected Data . Company knowledge and source-backed answers support the first. Saved outcomes, checkpoints and the investigator-to-coordinator handoff support the second. Graph investigations that identify affected commitments, resolve owners and create internal review tasks support the third. The connected-data action claim does not depend on a completed live Slack-to-ClickUp dispatch. High-concurrency autonomous-agent operation has not been benchmarked. OpenAI Codex assisted with coding, bug fixes, testing, deployment, documentation, and demo video preparation. I directed the product, developed the company scenarios, and reviewed the results. The video uses synthetic narration. I reviewed and tested the implementation and can explain its architecture, graph model, and technical decisions. Earlier documentation described pre-event prototype work. That history is preserved in the submission disclosure https://github.com/Haleem-code/Workweave/blob/main/docs/submission-disclosure.md ; this article does not claim that the entire implementation began during the event or that eligibility has been confirmed.