Inspiration

Every company has answers written down somewhere, but they only help if someone knows to look for them. A customer asks about a refund, and the policy says one thing while the FAQ says another. Production goes down, and people lose time working out who is on call. Most AI knowledge tools don't change this, because they still wait for someone to ask the right question.

I wanted a company brain that notices what is happening and acts on what it knows.

What it does

Cortex watches incoming GitHub issues throug arrives, an agent searches the company'sdocuments, decides what to do, and does it without a prompt:

  • Answers with citations: it posts a reply on the issue that names its source documents.
  • Routes work to the real owner: it findssigns the issue on GitHub if they have alogin. - Detects contradictions: each new documpassages, which is how it caught a 14-day and a 30-day refund window in the demo data. - Fills its own gaps: when it can't answp. One click drafts the missing document from what the company already knows and adds it to the brain, marked for review.
    ## How I built it
  • Backend: Python, FastAPI and SQLite - Search: SQLite FTS5 with BM25 ranking,
  • Agent: a tool-calling loop on the OpenAI API, capped at 6 rounds, with 8 tools for searching, looking up owners, querying live data and acting on GitHub
  • Live data: Triggerware's github_issues connector, polled every 20 seconds, with a Triggerware SQL query as a fallback
  • Frontend: a single HTML page with a live feed over Server-Sent Events, an action inbox and a Knowledge Gap Radar

Documents are ranked by BM25, which rewards rare terms that appear often in a passage:
$$ \text{score}(D, Q) = \sum_{t \in Q} \text{ID_1 + 1)}{f(t, D) + k_1 \left(1 - b + b\frac{|D|}{\text{avgdl}}\right)} $$ The important rules are enforced in code, not. A comment with missing or unknowncitations is rejected, the agent can only write to the issue it is handling, and tasks can only go to people named in the documents. This matters because issue te try to slip instructions into it.

Challenges

  • Triggerware account access: my login wreturned User not found, so I built andtested the rest of the agent with a clearly labeled manual trigger while waiting on account setup. The Triggerware integration is built, but its live connectio
  • The agent leaked internal details: in its first real run, the agent posted internal runbook commands in a public customer comment. Tests with a fake model conternal steps now go into the private taskinstead.
  • **It missed a contradiction it already kne the refund conflict, then answered "30 days" anyway because its search only returned one document. Known conflicts are now attached to search results.
  • It was too cautious: after drafting thagent still refused to answer because thedraft had open TODOs. It now shares what the draft establishes, says the process is under review, and promises nothing the draft leaves open.

What I learned

  • Testing with a real model matters. All my three most important behavior problems onlyappeared in real runs.
  • An agent that takes real actions needs lim alone doesn't guarantee behavior.
  • Saying "I don't know" is useful when it leads somewhere. Each unanswered question now shows which document the company should write next.

What's next

  • Finish the live Triggerware connection
  • Connect more tools, such as Slack and Jira, through Triggerware connectors
  • Add an approval step before sensitive acti

Built With

  • claude
Share this project:

Updates

Submission history