For Partners
There is no reasoning layer between your clients' prompts and their models. You can put one there.
In one line for your clients: a layer that makes every AI response better, every dollar attributable, and every decision auditable — without them building it. grāmatr is the layer that runs before every AI response — it classifies the request, assembles the right organizational context so the model returns better answers for fewer tokens, enforces policy, attributes every token, and compounds what the organization learns. Anneal, grāmatr's first application, is how you put that layer in your consultants' hands and your clients' architectures today, without building anything. One partner decision. Two wins, simultaneously.
Building a client AI practice on grāmatr? You're in the right place. Evaluating it for your own infrastructure? → For Enterprise
One deployment closes two gaps at once.
Partners are in two AI conversations simultaneously. With clients: is the model getting the right context for this request, who owns the audit trail, what does it cost to run, what happens when a regulator asks? With their own practice leadership: why are our consultants running AI across every engagement where classification happens nowhere, the right context loads from nowhere, costs are attributed to no one, and the organization compounds nothing? grāmatr closes both gaps with a single deployment decision.
Deploy Anneal to your consultants first. The full five-stage intelligence layer across the entire practice, from day one, running on grāmatr infrastructure. Every consultant session classified, context delivered precisely, policy enforced, cost attributed, and every interaction compounding the practice's accumulated intelligence. The practice is the first implementation — which means when a client asks whether this works at production load, the answer is not a simulation or a reference customer. It is your own practice's production record.
The partner relationship is not a software sale. It is an infrastructure commitment — the intelligence layer every AI deployment your clients run will depend on. grāmatr builds that commitment once, into an architecture that scales across your entire client portfolio.
Three tracks. One infrastructure layer.
Whether you are deploying Anneal to your own practice, delivering the intelligence layer to clients, or embedding grāmatr into your platform — the architecture is the same: classification, context delivery, governance, cost attribution, and compounding intelligence, running in the request path before every model response.
Deploy Anneal Across Your Practice
Consulting firms, Big 4, professional services organizations
Your consultants are running AI across every engagement. Classification happens nowhere. The right organizational context loads from nowhere — so the model returns generic answers where it could return precise ones. Costs are attributed to no one. The organization learns nothing from the aggregate. When a client's procurement team asks what governance controls were in place, the audit trail is empty. Every one of those gaps closes when Anneal runs on grāmatr. Deployed to your practice without building anything.
Every consultant session runs through grāmatr's five-function request path: intent classified before context loads, the right organizational context assembled for that specific request, policy evaluated and enforced before the model responds, cost attributed to the session at the moment it happens, and every interaction compounding the classification architecture's understanding of your practice's patterns. The longer your practice runs it, the more precisely it routes — and the more institutional intelligence accumulates under the same audit trail.
Deliver the Intelligence Layer to Clients
Systems integrators, management consulting firms, agencies
Your clients need the intelligence layer. They do not have the budget or the time to build it themselves. Anneal is licensed for client deployment as part of your delivery — you are not shipping a chatbot wrapper. You are delivering an application where every request is classified before the model responds, the right context is assembled so the model returns better answers for fewer tokens, policy is enforced in the request path, and every token is attributed to the session at the moment it happens. The audit trail your client's General Counsel can sign off on is a structural consequence of that architecture — not a feature added after the fact.
Each client deployment is fully isolated. Row-level security at the database layer means Client A's data is invisible to Client B by architecture. Partners can deploy across a regulated client portfolio — financial services, healthcare, government — with the isolation evidence to support due diligence. Every deployment tier means you can match any client security posture: multi-tenant grāmatr Cloud for the fast start (available now), private cloud and on-premises (committed September 1, 2026), or fully air-gapped on-premises (committed January 1, 2027) for clients with strict data sovereignty requirements.
Embed grāmatr in Your Platform
ISVs, SaaS platforms, platform companies
Your platform sends AI requests. grāmatr classifies them, assembles the right organizational context so the model returns better answers for fewer tokens, enforces policy, and attributes the cost — before the model responds, at sub-100ms latency, with no perceptible impact on your users' experience. You add the intelligence layer to your platform without building it yourself.
grāmatr is model-agnostic — Claude, GPT, Gemini, and Llama endpoints, any model your platform or your clients prefer. The intelligence layer travels when the model layer changes. Row-level security means each of your platform's users or tenants is isolated at the database layer. Patent-pending classification architecture. 99.9% SLA backed by fail-open design.
Two surfaces. Every deployment tier. Any client posture.
grāmatr is model-agnostic because the intelligence layer sits above the model layer. Classification, context delivery, policy enforcement, cost attribution, and compounding intelligence run in the request path regardless of which model the organization uses. Switch models when a better one arrives — the request-path intelligence, the audit trail, and every accumulated signal travel with you.
For platforms that support the Model Context Protocol. Claude Code, Cursor, Windsurf, and the growing ecosystem of MCP-enabled tools connect directly. The intelligence layer becomes part of the AI's request path — no middleware, no proxy, no additional latency beyond the sub-100ms pre-classification overhead.
For SaaS platforms and enterprise applications. POST a request, receive a classified intelligence packet — effort level, intent, relevant organizational context, behavioral directives — attributed and logged at the moment it happens. Authenticate with API keys, scope to individual users or tenants. The governance architecture runs in your request path without building it yourself.
Multi-tenant grāmatr Cloud for the fast start — tenants isolated at the database row level, never commingled, and available now. Private cloud for organizations with network isolation requirements — committed September 1, 2026. On-premises, committed September 1, 2026, and fully air-gapped on-premises, committed January 1, 2027, for clients where data must not leave their own infrastructure — financial services, healthcare, government. One architecture, four deployment tiers, same intelligence layer across all four.
Architecture your clients can verify. Not assurances they have to trust.
Governance is one of grāmatr's five functions — and for regulated clients, it is the one procurement teams will test first. Financial services, healthcare, legal, government — their procurement teams ask for evidence, not PDFs. grāmatr was architected from day one for the client who will audit what they deploy. The classification, context delivery, cost attribution, and compounding intelligence that run alongside the governance layer make the audit trail possible. A governance layer with nothing to audit is a log. This is architecture.
Audit trail in the request path, not reconstructed after
Every session through grāmatr generates a classification log — what was requested, how it was classified, what context was assembled, what policy was evaluated, and how the cost was attributed. The audit trail belongs to the organization. It is not a log export. It is architecture.
Row-level security at the database layer
Client isolation is enforced at the database layer. Client A's data is invisible to Client B by architecture — not by application-layer policy that can be misconfigured. Partners can deploy across a multi-client portfolio with the isolation evidence to satisfy regulated-industry due diligence.
SOC 2 Type I targeting October 15, 2026
grāmatr is in an active SOC 2 program. Type I target is October 15, 2026. Type II target is April 15, 2027. When a client's procurement team asks what certification standard this meets, the answer is a program in progress with dated targets — not a PDF assembled the night before the audit.
Session retention and configurable data governance
Session content is retained for 60 days by default, configurable to your application's needs. The governance audit trail is retained separately and longer. Encryption at rest. Every deployment tier — multi-tenant cloud (available now), private cloud and on-premises (committed September 1, 2026), through air-gapped on-premises (committed January 1, 2027) — for data residency requirements. Session-level attribution and governance logging throughout. Every governance event is captured in the audit trail.
For partners deploying in regulated industries: every classification decision, every context delivery, every policy evaluation, every cost attribution, and every governance event is traceable by design. Your clients do not have to trust that the AI behaved correctly. They can verify it.
Real applications run on grāmatr. That is the proof partners bring to clients.
For your practice, the model changes too: a tool deployment ends at go-live — an intelligence layer earns its place every day. An ongoing infrastructure relationship with recurring value, not a one-time invoice.
Before this site launched, grāmatr was already running Anneal in production — its first application — with the CPP (Covington Place Partners) financial-governance application in active development as the second. Every product, architecture, and go-to-market decision was classified, attributed, and logged through the infrastructure we are selling. Anneal runs in production on grāmatr today. That is not a case study or a reference customer; it is the audit trail of an architecture that has been running at production load. The full production record, with the classification, memory, and learning counts, is on the proof page at /platform/proof.
This is the answer to the single objection every client procurement team raises: how do we know this works before we commit? Most infrastructure vendors answer that question with a testimonial. grāmatr answers it with a production telemetry record and an architecture that has been dogfooding its own governance controls since before the first partner conversation. Partners carry that answer into every client engagement. It is not something a competitor can replicate by switching models or refreshing a pitch deck.
The economics of what you are delivering also change. A tool deployment ends at go-live. An intelligence layer earns its place in the client's architecture every day — because the classification architecture learns organizational patterns with use, the context delivery gets more precise, the cost attribution accumulates into a FinOps record, and the institutional intelligence that compounds under the same infrastructure becomes a switching cost the client chose to build. That is an ongoing infrastructure relationship with recurring value, not a software invoice.
Partner questions, direct answers.
How does the Anneal two-win work in practice?
You deploy Anneal to your consultants first — no build, no integration project. Every consultant session immediately runs through grāmatr's five-stage request path: intent classified, the right organizational context assembled so the model returns better answers for fewer tokens, policy enforced before the model responds, cost attributed at the moment it happens, and every interaction compounding the practice's intelligence. The practice has a full intelligence layer with session attribution and an audit log from day one. Simultaneously, your consultants are delivering the same infrastructure to clients. The two wins are structural: your practice is the first deployment, and every client engagement that follows runs on an architecture you have already validated internally. The practice production record is the proof you bring to client procurement.
What does the partner economics model look like?
Partner economics depend on your track: deploying Anneal for internal practice use, delivering Anneal to clients as part of your practice offering, or embedding grāmatr infrastructure into your own platform. Each track has a different structure, but the shape is consistent: you keep the majority of the value and services you build on top, while core product licensing carries standard resale margins. The specifics are scoped to your model and your volume under NDA. Start a partner inquiry and we will scope the economics to your situation.
How does client data isolation work?
Row-level security enforced at the database layer. Each client deployment is fully isolated — Client A's session data is invisible to Client B by architecture, not by application-layer policy. This is not a configuration option your clients have to trust was set correctly. It is the architecture. Partners can deploy across a regulated client portfolio with the isolation evidence to support due diligence in financial services, healthcare, and government.
What deployment models can we offer clients?
Four: multi-tenant grāmatr Cloud (available now), private cloud and on-premises (committed September 1, 2026), and air-gapped on-premises (committed January 1, 2027). The same governance architecture runs across all four deployment tiers — the same classification, the same audit trail, the same cost attribution. A client who starts on grāmatr Cloud can move to private cloud, on-premises, or fully air-gapped without re-architecting anything. Partners can say yes to any client security posture, including those that require data to never leave the client's own infrastructure.
What AI models does grāmatr support?
grāmatr is model-agnostic — Claude, GPT, Gemini, Llama, and any model your clients prefer. The intelligence layer sits above the model layer, so it functions regardless of which model runs below it. When a client's model preference changes — because a better model arrives, or because procurement requires a switch — the governance infrastructure, the audit trail, and the accumulated intelligence signals travel with it. No vendor lock-in on the model side.
How does the integration path work for ISVs and platform companies?
Two surfaces: an MCP server for AI-native platforms and a REST API for traditional integrations. If your platform already supports MCP, integration is configuration. For REST, the API surface is intentionally small — the architecture handles the governance complexity so your integration does not have to. Start a partner inquiry and we will scope the specific integration path for your platform architecture.
Partner arrangements range from referral and resale to joint delivery — the economics depend on your track and client base. grāmatr partner tracks are designed for firms building AI delivery as a practice, not a one-time project. A partner call is where the specifics land.
Start a partner inquiry.
Three tracks. One conversation to scope the right one for your practice. Start a Partner Inquiry
See the full platform architecture at grāmatr for Enterprise or review the platform overview.