Introducing Alignbase: your company-wide AGENTS.md
The engineers that used to write the code knew the company, product, and policies. Now, the agents writing the code don’t.
It’s easy to give agents access to the internal wiki or Skills repo, and those solutions have their place. It’s one thing to give agents context they CAN use and another to inject context they MUST use.
The AGENTS.md forces context uptake within a code repository, but these files are static and they don’t cross repo, user, and web agent boundaries cleanly. Alignbase unifies shared context under a single remote repository.
Context needs to be treated as a first-class citizen. It’s scarce and it’s valuable. Context needs optimization, authentication, permissions, audits, and approvals. Alignbase does that. Wikis, Skills, AGENTS.md, and “company brains” don’t.
That shared Github repo isn’t enough. Who’s allowed to define what the company is? What the team’s policies are? Is that enforced? Is access authenticated? Is delivery dynamic? How do you immediately tell all your company’s agents about your ongoing AWS outage?
Alignbase is the first shared context repository and context control plane. Grateful for any and all feedback!
Top comments (5)
Really liked this framing, Abe. The “context they CAN use” vs “context they MUST use” distinction is the part that hits hardest for me.
I’ve been looking at a related pain for a while: every agent/tool ends up creating its own place for project context — .claude, .cursor, .codex, .windsurf, etc. Same meaning, different folders, lots of drift. It feels like teams are slowly rebuilding the same context layer over and over, just under different brand names.
That’s the direction behind APC (Agent Project Context): agentprojectcontext.com. The idea is simpler than a platform: one neutral project context layer that can live with the repo and be readable by different agents/tools.
Reading your post, I see some overlap in the problem space, even if Alignbase seems focused more on company-wide context, governance, and dynamic delivery. APC is more about the portable project/repo layer.
Do you think there could be a useful connection between those two angles? I’d be happy if you take a look and tell me whether you see any common ground, or if there’s something worth exploring together.
Nice! How is APC different from AGENTS.md?
And i add this:
dev.to/agentprojectcontext/apx-ini...
Some comments may only be visible to logged-in visitors. Sign in to view all comments.