Engineering intelligence on demand.

The problem

You wrote the standards. Nothing reads them.

• Never arrives

  You wrote the standards. There is a 40-page PDF, a Notion space, three ADRs. None of it is open at 16:40 on a Thursday when the endpoint gets written.

• Drifts

  So you copied the rules into every repo. Now you have eleven handbooks diverging in eleven directions, and nobody can tell you which one is current.

• Rots

  No owner, no review date, no way to tell a live standard from a fossil. So engineers stop trusting any of it, which is rational.

• Agents ignore it

  Your agent generates to its training priors — the average of GitHub — not to your layering, your error contract, your migration policy. It is confidently wrong in your house style's exact shape.

• Skill fatigue

  The fix on offer is to install more: a skill per framework, a server per vendor, a rules file per repo. Each one costs context on every request and has to be learned, versioned and pruned by someone. You are now maintaining a tool budget instead of shipping.

All five have the same root cause. The knowledge lives somewhere that is not where the work happens, so it has to be carried there by a human who remembers. Under deadline, nobody remembers — which is exactly when the rules mattered.

A CLAUDE.md per repo fixes maybe 60% of this for free and you should do it today. Athena exists for the part that does not fit in 100 lines and must not be copied eleven times.

How it works

Knowledge on demand, in four pillars.

Athena serves what the task needs, in the shape the task needs it: graded rules, working guides, multi-step flows, or deep research. The agent asks for what it is trying to get done; the pillar decides what comes back.

The four pillars are the interface, not the filing system. Underneath they stay organised by topic, and neither the topics nor the filing are something a caller can walk.

The mechanism

Watch an agent do the reading.

The agent describes its task. Athena tells it which pillar and which call, returns exactly what that step needs, and the agent comes back citing the standard it used — by name, so you can open it and argue with it. A small toolbox, not forty tools.

An agent cannot create or alter a rule. It can ask, and it can report that something was missing. It cannot promote its own opinion into the standard it will be judged against next week. The standards change through reviewed pull requests.

Categories are the four pillars above. Route, get and feedback serve all of them. Responses are capped and scoped to the question asked: there is no bulk call, no listing, no count of what exists and no directory to walk — athena_get redeems a reference Athena already issued rather than looking anything up by address, and athena_feedback is the only tool that writes, with what it writes being a report, never a rule.

Context economy

Ask for the rules, not the library.

Context is the budget you are actually spending. A 200 KB handbook in every session is worse retrieval than three relevant pages, and it crowds out the code the agent is supposed to be reading.

So the rules are served separately from the prose. athena_rules returns the graded assertions for what the change actually touches — about 2 KB — with no rationale, no examples, no diagrams. That is what an agent needs to enforce a standard. The why is still one athena_get away, for the human who wants to argue — the rules response carries the reference, and redeeming it is what brings the prose back.

Same reason the toolbox is small instead of forty tools. Every tool schema is injected into context on every request. A large toolbox makes an agent worse, not better.

Breadth

The build is one stage out of twelve.

Teams adopt AI at the point where code gets typed and wonder why throughput barely moves. The expensive parts are upstream and downstream: deciding what to build, breaking it down honestly, and finding out why it broke in production.

Athena carries the standard for every stage, and the gate between each one. Agents draft. Humans decide. The artefacts — a spec, a plan, a reviewed diff — are what make the next stage cheap.

• “Is this library approved?”

  The approved-list entry and the eight criteria to score it — or 'not decided yet', when that is the truth.

The lifecycle page is in review and several stages are still being expanded. The twelve stages and the gate between each one are real; depth behind every one of them is not claimed yet.

Scaffolding

A new service, to your standard, in 30 minutes on prod.

The agent reads the setup pages, asks you the four questions it is not allowed to decide, runs the generator, applies the post-generation delta, and then verifies the day-zero checklist item by item with evidence.

It does not create the repo, the cloud resources or the secrets. It writes the infrastructure and the commands; you run them. An agent that provisions unattended is an unreviewed deploy.

$ uvx cookiecutter gh:cookiecutter/cookiecutter-django
project_name · use_docker: y · postgresql_version · cloud_provider: GCP …
answers come from the handbook's answer table, prompt by prompt

Time to live

Minutes to a deployed skeleton. Thirty to your first feature PR on prod.

What takes minutes: a service that builds, runs in a container, passes CI, reports errors to Sentry and reaches staging. Not because anything was skipped — because the generator, the multi-stage image, the compose files, the CI workflow and the error tracking are standards Athena hands the agent, not decisions you make at 16:40 on a Thursday.

What takes the rest of the 30 minutes: the day-zero checklist. Owner, tier, data ownership, branch protection, secrets, infrastructure, the layer contract, the runbook. We will not tell you that part is instant. We will tell you it gets done, item by item with evidence, instead of becoming a ticket nobody picks up.

Measured: “minutes” from uvx cookiecutter to a green pipeline, a container in staging and Sentry receiving events. “Thirty minutes” from the same start to the first reviewed feature pull request on prod with the checklist complete. Both are handbook pages, linked from this one — not marketing claims.

Four environments from the first commit — one image, built once and promoted. Parity is the shape the service starts in, not a later project. And the same shape three times: FastAPI, Django, React. One handbook, one layering, one delivery path.

Building agents

An MCP server that teaches you how to build MCP servers.

Our stack is Python, LangGraph and Claude. The questions that cost weeks are not “how do I call a model”. They are: should this be an agent at all, or a function? Where do the boundaries go? How do you retrieve without poisoning your own context? What makes a tool an agent uses correctly rather than confidently wrong? What happens when a tool result contains an instruction?

Athena is an instance of its own answers. A small toolbox, not forty tools, because every schema costs context. No agent writes to the standards — it can ask, and it can report what was missing; changing a rule takes a reviewed pull request. Rules served apart from prose. Tool output treated as untrusted. You can read the design and the decision record for the thing you are connecting — then disagree with it in a pull request.

Debugging

From production error to reproducing test.

Sentry already holds the stack frame, the locals, the release and the suspect commit. Athena holds the rule that says the agent must reproduce the failure with a test before it proposes a fix.

No reproduction, no fix. If the agent cannot reproduce it, its output is a hypothesis and it has to say so. And it never resolves the issue — closing an issue is a claim that the defect is gone, and only a human gets to make it.

Standards as code

Every rule is graded. Most are enforced.

Colour is never the only carrier here. Each state spells itself out — queued, forbidden, passed — so the sequence survives greyscale and a screen reader unchanged.

Where this is

Early, and honest about it.

13 pillars, 120 pages. Every page has an owner and a review date, and the backlog is claimable rather than hidden. These counts are read from the handbook's generated status file when this page is built, so they cannot drift from the repository.

adopted

38

in force — a pull request that breaks a MUST here does not merge

review

4

substantially written, open for comment

draft

73

a stub listing the questions the page will answer, claimable

blocked

5

waiting on a decision, not on effort

Where it is going

Solid markers are phases that have started. Outlines are phases that have not. There is no growth curve here and no logo wall, because neither would be true.

1. 1 · Handbook

   Pillar structure, flagship pages, templates, ADRs, validation CI

   Done

2. 2 · Coverage

   Close the draft backlog, pillar by pillar

   In progress

3. 3 · Retrieval

   The MCP server on Cloud Run: route a task, return the rules, the guide, the flow or the research it needs

   ADR-0002 and ADR-0010, in build

4. 4 · Skills

   A plugin bundling handbook, standards-review, new-service, debug-from-sentry

   Designed, not started

5. 5 · Enforcement

   Lint rules and CI gates behind every MUST that can have one

   Partial

6. 6 · Publish

   Decided against. The corpus stays private and is reached through Athena, not read as files

   Closed

Objections

The questions you were going to ask.