Lukuku OS · company ontology and agent operations
Period — Present
Staff and agents query the same graph of company information. Agents divide development work among themselves, subject to human approval.
Links original sources from 15 places, including Slack, email and GitHub, to 120+ clients and projects
- A source archive that stores and searches more than 500,000 Slack messages
Searching several places to understand a client
- Problem
- Understanding a client required separate searches through Slack, email, documents and repositories. The hand‑maintained internal wiki had stopped being updated, with 51 pages left empty.
- Solution
- The system collects 15 sources on a schedule and rebuilds the graph daily. It keeps only relationships with source links and retains the last working graph if collection fails. As of 2026.11, the graph contains about 280 entities and about 4,150 relationships, and every employee has used it since 2026.09.
Ontology: what links to what, and in which terms
- Problem
- Mixing similarly named entities or relationships with different meanings produces incorrect answers. Without fixed relationship names, the same fact was spread across different wordings.
- Solution
- Defined 20 relationship types to specify what can be connected and how. Each task is also linked to who took on which responsibility. This added 100 responsibility relationships across tasks.
Whether the graph can answer questions on its own
- Problem
- A larger graph did not show whether it could answer actual work questions.
- Solution
- Daily checks run fixed questions with expected answers drawn from original sources and locate the step where an unanswered question gets stuck. Relationships extracted from Slack enter the graph only when two different model families agree.
Vendors that lived only in attachments
- Problem
- Payment, logistics and identity verification vendors appeared only in attachment text, not in the graph.
- Solution
- I took proper nouns next to words describing a role as vendor candidates and added only those a person confirmed. I treated a guessed vendor as worse than a missing one. Vendors in the graph grew from 20 to 24.
Actions that are hard to undo
- Problem
- Agents needed to execute work while actions that are hard to reverse remained restricted. One agent once ignored its instructions and replied in a client thread.
- Solution
- Split permissions by stage of work (investigation, implementation and review) rather than by topic. Investigation and review agents only read, and the implementation agent commits but cannot merge or deploy. The agent that watches client channels has no permission to post. Apart from incident response, deployments, external messages and production data changes require human approval.
Architecture
Request sorting · assignment · result collection
Company ontology
- Collection
Slack · email · canvases · attachments · repositories · task records
- Slack source archive
More than 500,000 messages · full‑text search · attachment originals with a separate catalog
- Wiki graph
Recalculated daily · only relationships with source links retained
- Relationship rules
Allowed relationships and evidence grades defined in one file
- Company records
Decisions · open questions · memories · human review before updates
Knowledge access
- offon MCP
OAuth · writes within the requester's permissions
- Answer evaluation
Runs fixed questions daily · diagnoses why answers failed
Development
- Investigation
Read‑only root‑cause analysis
- Implementation
Commits in a separate workspace · no merge or deployment
- Review
Uses a different model from the author's
Task handling
- Task monitoring
Posts tasks from Slack conversations to offon · leaves items with unclear evidence as they are
RequestTask assignmentImplementation and commitDifferent model reviewHuman approvalPost‑deployment check
