Launch HN: Almanac (YC S26) – AI that knows your company (usealmanac.com)

4 points by kushagrchitkar ↗ HN
Hi HN, I'm Kushagra, one of three founders of Almanac, a Hermes with a brain that knows everything about your company.

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 ] thread
7-day trial seems kind of narrow for a product that needs to "build a memory", no?
Given it has "logins" to tools without APIs (browser-based access), how do they handle 2FA, session persistence, and ToS violations for services that don't allow bot access?
Our browser is interactive, in the sense that one could click around the browser, as well as the agent. Usually for 2FA logins, Almanac would hand it over to the human, who'd complete login, and then continue.

We 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.

> that knows everything about your company

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

why "apologies for twitter link"?
(comment deleted)
Twitter doesn't show an author's follow on tweets to an initial tweet when the viewer is not logged in, and people frequently post their twitter thoughts in chains of tweets rather than in the one post. Historically people would therefore post links to sites like xcancel that showed the full content instead, but it appears to be dead.

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.

Microsoft WorkIQ but for companies on a non-MS stack
If AI has achieved anything it's a dramatic increase in documentation quality for the sake of training or instructions.

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.

The documentation is not just for lookup queries. Having this layer betters the quality of responses, but also enables a lot of features we have in Almanac/plant to add. I mentioned in the post how this layer enables proactive agents and long horizon tasks. I just came across a Google paper yesterday (https://arxiv.org/html/2608.27454v1) that use a similar wiki knowledge base to self improve agent skills. I think these are just scratching the surface of ideas of what's possible with this layer
The website tells me absolutely nothing about what makes this new or unique
"You text it work. It texts you when it's done." this should have a comma not a period.
Congratulations on the launch! The demo in the video you linked looks awesome (though your video resolution is a bit low, some of the text is hard to read on screen, I suggest you record in higher resolution). I think you made a really good choice to have your connector provider handle OAuth credentials, since it is really hard to get security right on a multitenant app like yours, where some of your agents are doing work on customers' behalf and others are improving your product itself :). The design of your app interface also looks really great!
There is a lot of competition in this space, both commercial companies and open source. It seems like the biggest advantage for using one of these and not Claude or Codex is that you can use multiple models. Otherwise, those two have all the same features, or probably will in the next week.

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.

Currently we don't allow for multiple model selection, but it is on the roadmap. We do have a cli, which allows you to use the wiki layer and the tools in whatever harness you prefer. Further, we want to allow users to also bring their own keys/subscription.

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

> Currently we don't allow for multiple model selection, but it is on the roadmap.

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)?

How are you different from the following cos?

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

There is truly a lot of competition in the space. The reason we're confident we stand out is because of our wiki layer. We have seen both the benefits of having a detailed compiled wiki, and more importantly, actually using this layer to then power capabilities. Two such examples are written in the post as proactive agents and the handling long horizon tasks. I believe this is still just scratching the surface. Having the perfect context layer makes every single task you do with agents much moe powerful
Wishing you guys the best, but this isn't a very compelling answer. Would be helpful to provide more concrete or quantifiable examples. In the early stages when pitching to users, it's preferable to state exactly what can be done now.
How do you manage permissions in the wiki? Does it require all content being available to everyone in the org or does it do some sort of vectorizing that is unique to every single user based on their perms? Whenever we've tried to build something similar, permissions is usually the first headache and is often why something like Microsoft's WorkIQ is appealing (if you're an O365 org).
The current permission implementation is binary. It is either personal to you, or is shared with everyone in the company. Having more granular permissions is something that has been requested often, and it is on our roadmap. I'm curious, how does Microsoft WorkIQ handle these permissions?
The source-retention detail seems more important than the model list: if an email is compiled into a wiki and later deleted, or access is revoked, how quickly does that fact disappear from the personal or company wiki? Is the wiki rebuilt from current source state, or are removals handled as a separate event?
Wiki updates happen once a day through. That is when the entire day's context is updated in the wiki. That is when the fact disappearance would take place
Really simple and well designed website for the brand identity. Logo, background, UI and FAQ all flows well. Feel like I trust the project without knowing much about it or having the usual “trusted by” section. Keep it up!
Don’t have time to dig deep into it this afternoon, but want to comment to come back but also to suggest an expansion past your stated “one personal and one company” wiki.

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’.”

I agree with the take. This was on the roadmap, but given the responses today, we will make permissions inside the company a bigger priority. To brainstorm, would you want the ability to define teams inside a company as well? I was thinking admins/owners could create teams and select the people they want, and then their permissions
I suspect nearly “any” solution is good enough to get started and learn what users use and like.

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 ;) )

Hi ! Are you guys looking for interns or smth right now , this looks like something I would want to work on xD
Hey, glad you found it interesting to work on. We're not looking for interns right now, but shoot me an email at kushagra@usealmanac.com, would love to keep people in mind
I think it should be called Yet Another Second brain. In past 2 months, almost everyday there is a company pitching the same thing. That means, it is going to be supercrowded and nobody wins or it is feature and not a product by itself.

Standalone product becomes another platform with IT implementation that you can already do with existing product in the stack

The interesting tradeoff here is not just better retrieval, but whether the pre-compiled wiki makes behavior more predictable over long-running tasks. It would be useful to see comparisons against a plain markdown repo plus Claude/Codex: task completion, citation accuracy, stale-context failures, and the cost of keeping the wiki updated. Multi-model support and bring-your-own-key options also seem important for enterprises that don't want their company's context tied to a single provider.
We have been debating what the best benchmark to show would be. I'd love to test it out on long horizon tasks, but then we're thinking of best to make the base wiki to test it out
Looks identical to Claude Desktop connectors.

This is a feature, not a product.

Congrats on the launch, the approach of spending compute upfront is a compelling shift from what the current standard is.

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?

This is an interesting edge case. When something similar happened, Almanac texted me asking for an update if I had followed up on email, and then I mentioned that I had followed up. So in this sense there was a HITL. A good solution could be to have account provenance for tasks, so that disconnection on accounts could update stale context
The hard part for an always-on company agent is what survives a restart. My runtime snapshots the whole JS heap to bytes and restores it in a fresh process, so conversation and working state come back with no serialization code — but timers don't survive, so an agent re-arms them from declarative state after restore. How do you handle that? Is a long-lived agent's state checkpointed, or rebuilt by replaying context on each wake?