Workweave：將公司資訊轉化為實際行動的 AI 知識中樞

What if your company information could help your team decide what to do next?

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 · Source code · Watch the 3:50 demo

First, tell Workweave about your company

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.

How a company question gets answered

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.

How Slack connects to Workweave

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.

How the AI decides whether a message needs a task

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.

How Workweave finds someone who can do the work

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:

• How well the person's role and responsibilities match the request.
• Similar tasks recorded as completed on time.
• Relevant tasks recorded as late or reassigned.
• How much open work is already recorded for that person.

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.

How the ClickUp task gets created

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:

1. The original Slack request.
2. The proposed task title and description.
3. The suggested person and other candidates.
4. The matching factors, recorded paths, and available document evidence.

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.

What happens if a connection fails?

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.

What the app remembers

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.

Why the demo includes a delivery delay

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.

A simple view of the architecture

• Next.js and React: the interface people use.
• 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: stores credentials separately from company knowledge.

See the architecture diagrams and source-file map.

What has actually been tested?

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.

Try the company packs.

What I learned

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.

Tracks and build disclosure

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; this article does not claim that the entire implementation began during the event or that eligibility has been confirmed.

Open Workweave · Watch the demo · View the code