Launch HN: Almanac (YC S26) – AI that knows your company (usealmanac.com)
We started our journey with setting up Hermes for our company, thinking it must be easy. We wanted an agent that would know every context about our company, so we could ask questions and get context-appropriate responses to.
This started a very annoying and difficult journey. Setting up Hermes, getting it to talk right, building OAuth apps for every connector myself, then feeding it context myself, and ultimately struggling with Hermes's default memory. At the same time, we saw our YC batchmates struggling with the same problem, and we saw an opportunity.
So we built Almanac. This is how it works. You sign up, you get a Hermes agent straight out of the box. You have a one-click connect to any account (Gmail, Calendar, Granola, PostHog, etc). You have personal accounts (only accessible by you) and also shared accounts (accessible by everyone in the company). The consequence being I can never see my cofounders' accounts.
The “brain” of this agent is wikis. We pull in information from your connected sources, and start organizing this information in two wikis. A personal one, for you, which understands who you are, what your preferences are, the people in your life, and the things going on in your life. The second wiki is a company wiki, which includes what the company is, what you’re working on, what the roadmap is, and what the blockers of the company are. Your agent ultimately has access to these two wikis and the original accounts, which invoke the feeling of “it just knows you.”
Here’s a demo: https://www.youtube.com/watch?v=ajXP5PHuK18
We're three cofounders, Rohan, Kushagra, and Divit, and we've been friends for 11 years, since studying for the IIT-JEE. We all did Electrical Engineering (Rohan at IIT Delhi, me at IIT Kharagpur, Divit at BITS Pilani, Hyderabad), and Rohan and I later went to Harvard, where this pre-compilation layer became our capstone thesis. We have built multiple products around the idea of a pre-compiled knowledge layer.
Our main differentiating point is the way we approach memory and context in general. Most AI assistant tools treat memory as an afterthought. We have worked on wikis for AI for more than a year now, building products for Harvard and NASA. The one thing we have learnt is that one needs to spend a lot more compute upfront, in the pre-compilation of this knowledge base, to get it right.
Having this pre-compiled knowledge base enables a lot of interesting ideas. First is a proactive agent. Since I have compiled what’s going on in both my company and my current life, Almanac can start completing tasks on its own. Concretely, we run a background worker which takes a look at tasks that could be completed, pings the main agent, who then pings me, suggesting which tasks it could automate. As a result, I wake up to proactive notifications which look like “I already prepared a draft of your fundraising pitch deck, want to take a look?”
Second, long-horizon tasks. In our wikis, we maintain a section on ongoing projects, so Almanac can pick a task back up days later without losing the thread. Most agents are session-bound: they run once, finish, and forget. But a lot of real work isn't one shot; it plays out over hours and days with people in the loop. The clearest example is anything that involves waiting on a human, like scheduling a meeting, following up on a sales thread, or chasing a document. Almanac can send an email on your behalf, and because it's always on and remembers the project, it notices the reply four hours later and drafts the right follow-up in context.
Since launching, we've seen a lot of use cases for Almanac. One person runs her dog-rescue operation through it: finding available fosters, tracking pickups, and sending reminders for consent forms. Another researches Polymarket ...
43 comments
[ 0.41 ms ] story [ 7.5 ms ] threadWe use Browserbase for the browser and session persistence is inbuilt.
For ToS violations, this is a limitation. Accessing sites that don't allow for bot access could result in account ban/suspension. Simply using Browserbase under the hood does not remove this risk.
Given that I don't know everything about my 4-person company, and that I never knew everything when it was a 1-person company (guess which person is that), this sound like https://x.com/mitchellh/status/2044529496217555333
So reading the linked post, I have no idea if that's the whole thing or if that's just the introductory statement to a larger idea.
I'd argue that if documentation on how to operate your business can be used to feed an agent, your problem was never the ability to run operations and the ROI will amount to the ability to ask instead of doing. I don't know how much this is gonna go for, but you could probably have one of your existing staff just do basic documentation lookups too.
Are you able to use multiple models? Or I guess the first question is, what model(s) are you using? At this point, many enterprises care so that should be front and center, especially if you're using models hosted in China, because a lot of non-Chinese companies care about that.
You mention some things about unique ways to store memory. Do you have any data or use cases on how that improves performance? If you do, you should get those on your website too.
And also there is a small nit with your website. The graphic next to "Proactively gets things done for you" gets bigger and smaller, so if you're trying to read anything below that, it keeps jumping up and down.
We do not have formal benchmarks to measure improvement in performance. A big reason is that most benchmarks are very "atomic facts memory" focused. They'd give a huge passage, conversations, and see which memory system could surface those facts. How we're different is agents could be simply given the markdown files, and they can pretty much get the perfect context themselves. Second, we are banking more on the fact that having this layer enables new capabilities of the models
Cool! What model does it use now? Enterprises will definitely want to know.
And the other big question: Why not just use Claude or Codex (via CLI on a desktop or droplet)?
OpenTag
Turnstone
Memory Store
Hyper
Hyperspell
Wato
Savant
Shepherd
Glen
OpenTag
Janet AI
screenpipe
Cerenovus
jo
Bond
Airweave
Mem0
Theta
Nessie
Mosaic
Onyx
Slite
Dashworks
Circleback
Stamp
Tasklet
Within
Khoj
I lead two different functional areas within tech and work in a larger tech platform for the parent company of a couple dozen operating companies.
All that to say “I would almost surely be better served by a hierarchy or general graph of wikis rather than just ‘me’ or ‘all 15K employees’.”
In my guessed-at ideal world, assuming the permissions setting isn’t complex, I’d like the ability for a user to define multiple teams and manage them with an easy method. Maybe that’s an API; maybe it’s a periodic ingest of a csv file. If you must have “admins” and “users” (rather than mostly users who can share teams they create), that will be an ok way to start, but I would bias towards “there are a tiny number of true admins but almost everyone is a user and users can share teams with other users”.
We’re very comfortable with storing config data like this in git and it would be great for tech teams to adjust team ownership by commit/pushing csv files, but that might not fit your actual user base (or the purchase-decision-making subset ;) )
Standalone product becomes another platform with IT implementation that you can already do with existing product in the stack
This is a feature, not a product.
I am curious as to how you handle state invalidation and unseen side-channels during those long-running tasks, because if the agent pauses a task for X days, say waiting for an email reply, but the projects params changed offline or in a channel that the agent has no eyes on, how does the system realize that the pre-compiled context has now gone stale? Does that also mean that proactive actions always require a HITL?