Ask HN: Are you building an AI company brain?
- draft emails or presentations.
- prepare meetings and provide the current context to the employees.
- update clients information after meeting based on transcripts or employee notes.
- query different sources in order to gather how our system is working for a particular client.
I've been looking for ways to implement this but I can't seem to get to a clear path, I've some online sources and a few things in mind but I'm not convinced enough.
My current plan is the following one:
- A llm wiki to store "slow moving" data: company strategy, OKRs, clients status, transcripts..
- "fast moving" data (databases, logs, client tickets) has to be retrieved directly from sources, maybe using some company shared skills.
- Each employee can use a coding agent or a chat interface to "communicate" with the data through a MCP or something.
- There's an 24x7 agent who owns the llm wiki and skills repo and has access and knowledge about how to get data from the "fast moving" sources.
That is my current idea but I've so many doubts to move forward: - the 24x7 agent has to be constantly working, how much money could it cost?
- what happens when multiple people are working on the same data at the same time? can the agent do something to orchestrate the work?
- what kind of agent should I put there?
- Do I need to put an agent there?
- is there a better way to accomplish this? Am I over complicating things? Am I over simplifying things?
Are you working on this? What do you think? What would you do if you were in my shoes? (quitting is not possible :))
22 comments
[ 0.20 ms ] story [ 15.2 ms ] threadWhen I recently spoke to their engineers about this, they mentioned graph maintenance is very expensive and would likely be cost prohibitive for most orgs.
"some sort of entity that keeps the context of what's going on in the company"
This is the killer piece, because I know what it would mean to me, but did CTO give you a clear indicator of what he means? All the meetings, drafts and whathaveyou won't automatically capture those.
- wiki equivalent is good, but it comes with the expectation that it is updated, current and accurate ( with as little as possible not listed -- which can be a pickle for some uses ) - databases - you want to be careful here for obvious reasons esp if your databases hold anything beyond simple purchase orders - 24x7 agent could cost less long term if you go for local inference ( and accept some speed trade-offs ) - orchestration - there is a lot money sloshing around this one including big boys - I did not see good corporate orchestration suite yet ( though I am sure it exists )
<< is there a better way to accomplish this? Am I over complicating things? Am I over simplifying things?
Maybe. Get the feel whether CTO is actually asking for a prettier dashboard or something more meaningful. I am not joking.
Some basic tips I hope that help you.
1. When the system is up and running don't run agents in a loop, wake them up when something happens. An email arrives, something changed, a timer triggered. There is no reason for 24x7 agents most of the time.
2. You want a system that does not allow conflicts, as your baseline, for projects where many people are working on the same thing. Think git for documents. How is not important, it's important that it's there
3. A basic coding harness like Claude Code is going to do a million times better than anything you can build yourself. It's already optimized for dealing with tasks in a complex environment and gets updated near daily. Don't roll something yourself or buy a special solution from a vendor
4. It's super easy to provide context for a meeting. It's very hard to get people to read them. Spend time making sure pre-reads are short, concise and relevant.
5. Only have one source of truth for core data. An AI agent will happily find an outdated document and assume that's the truth. Make sure it's strongly enforced that important structured data is in an easy to search single database.
Build it incrementally. Pester your CTO about what task is the most important then start there. Spend your time collecting feedback from the people who use the system and build as little as possible. Very easy to add every feature, harder to make sure you only build the features that make the system better.
When that is said, this could easily become a very fun project to work on! Feel free to reach out if you get blocked.
The write operations will be made only for the documents included in the repo if the agent allows it according to user permissions. Am I right or did I get something wrong?
I'm also thinking about "real time data" like google docs, chats, transcripts, databases, logs...
My current idea would be to keep that out of this repo and have each user to query them (if they have permissions) with their own personal account. This way the system is more simple and maybe cheaper because each employee can use their current Agent plan instead of the service API tokens that are way more expensive and difficult to limit.
What do you think about this?
- This is interesting but more complex https://github.com/langchain-ai/design-agent. - This talk points to something similar but ingesting all the data into the system and chunking it to allow semantic search later https://ai.engineer/talks/KWmkMV0FNwQ-building-alices-brain-...
Plase tell your experience (I'll take a look at https://github.com/desplega-ai/agent-swarm/)
"El más grande sigue siendo River plate"
Barcelona or Real Madrid?
Tbh, with the swarm, we cover for that particular need. The caveat is that we don't try to be the SOT. At the end of the day, your company knowledge is distributed by design, so you're system needs to account for that. Instead of trying to have everything up to date, you need to remember where to look for the knowledge... even if it means burning a bit more tokens.
So, trust me, it is way more complex to do, an AI model is not do to analyse big data, even LLM have limits... the hardest part is to keep this information structured, correct and well organized at the speed of AI, without costing too much. The risk is to create more and more false information and the system become unmaintable... or you spend your life on it.
One trick, if you want to do something like that, create a node based graph knowledge base, it is just the start. Noticed that we are looking to release our brain db (working on it since a year now... it is amazing, but complex to exploit it in production), but I do not know when... the plan is not clear, we use it internaly only for now.