Almanac Health

The agent is the product: retrieval, summarization, note drafting, order placement, and alerting, with the model selecting and chaining its own tools to complete a request. Nothing remains without it.

The most precisely specified autonomy position in the index, because the company names its own level. Almanac Copilot is described as a Level 1 autonomous agent: it acts only on explicit clinician command and requires the clinician to review and approve every action before it takes effect. Publishing a stated autonomy tier, rather than describing capability and leaving the ceiling implicit, is a practice more vendors in this index should adopt.

Unusually specific for an early stage company. The tool set available to the agent is enumerated (FHIR functions, browser, clinical calculators, Python interpreter, EHR database), the grounding approach is stated as retrieval from a vector database of peer reviewed evidence rather than unconstrained generation, and performance is reported against a named public benchmark, EHR QA, at 74 percent task completion across 300 tasks. Reporting against an external benchmark with a stated task count is rare here.

Nothing substantive on patient data handling could be retrieved: no published statement on retention, deletion, de identification, secondary use, model training or sub processors, and no model or hosting arrangement named. The company states that its research and development prioritises privacy and reliability and that institutional data remains secure, and neither statement identifies a control or a commitment.

The stage explains much of this and should be said plainly rather than left implicit. This is an early company that announced a seed financing in 2026, so an undeveloped compliance surface is expected rather than evasive, and this grade records what a buyer can verify today rather than a judgement about the engineering or the intent.

One item is checkable and worth flagging on that basis alone: the privacy policy address published in the company's application store listing did not resolve when retrieved, returning a not found error. That may be a routing problem rather than an absent document and should be rechecked, and a clinical application distributed to healthcare professionals should have a reachable privacy policy at the address it publishes, because that address is what an institution's review will check.

The product design makes the questions concrete, since the platform integrates record data and operates inside the record rather than beside it. Ask what is retained from a clinical query, whether query or record content improves the models, and where processing occurs.

Research pedigree is genuine, with the founder's Stanford work introducing retrieval augmented generation to clinical medicine among NEJM AI's most cited papers, and benchmark performance is reported against EHR QA. But the company characterizes the platform as validated through research rather than shipped as a finished product, and states it is still undergoing clinical validation in academic medical center settings. Benchmark completion is not clinical outcome evidence, and buyers should treat this as an early platform with strong provenance rather than a proven deployment.

Nothing substantive on patient data handling could be retrieved. There is no published statement on retention, deletion, de identification, secondary use, model training or subprocessors. The company states that its research and development prioritises privacy and reliability and that institutional data remains secure, but neither statement identifies a control or a commitment.

The stage explains much of this and should be said plainly: Almanac Health announced a seed financing in April 2026 and remains an early company, so an undeveloped compliance surface is expected rather than evasive. The grade records what a buyer can verify today, not a judgement about the engineering.

One item is checkable and worth flagging. The privacy policy address published in the company's App Store listing did not resolve when retrieved for this assessment, returning a not found error. That may be a routing problem rather than an absent document, and it should be rechecked, but a clinical application distributed to healthcare professionals should have a reachable privacy policy at the address it publishes.

The question that matters most here follows from the product design. The platform is described as integrating electronic health record data and operating inside the record rather than beside it, so it will handle patient information. Buyers should ask what is retained from a clinical query, whether query content or record data is used to improve the models, and where that data is processed.

No HIPAA statement, business associate agreement, template or terms of any kind were located in any retrieved material. The company does not identify itself as a business associate and does not address the relationship.

This is a gap rather than a considered position, and it matters because the product is not designed to sit outside the data path. Unlike a pure reference resource that disclaims handling patient information, Almanac positions itself as an intelligence layer embedded inside electronic health record environments and integrating record data, which places it squarely in business associate territory once deployed.

The company's own framing of being governed by institutional controls implies a health system contracting relationship, and a health system will require a business associate agreement before that deployment proceeds. Buyers should ask for it early, since its absence from public material at this stage says nothing about whether one exists in a contracting process. Expect this axis to move as the company matures.

No trust centre, security page, certification or third party attestation was located. No SOC 2, HITRUST or ISO 27001 claim appears in any retrieved material, and no security controls are described beyond a general commitment that institutional data remains secure.

This is age appropriate rather than remarkable. The company announced a ten million dollar seed round in April 2026, bringing total funding to roughly twelve million, and independent security attestation is normally a later step for a company at that stage. Recording it as C reflects what a buyer can verify rather than an assessment of the underlying engineering.

It does become a live constraint quickly, and in a specific way. The company states it is undergoing clinical validation in academic medical centre settings, and academic medical centres run some of the most demanding vendor security reviews in healthcare. A published attestation is usually a precondition for moving from validation into production there. Buyers should ask what the company holds today, what is in progress, and on what timeline. This is the axis most likely to move first.

No clearance, authorisation or published regulatory position was located. The grade reflects the absence of a stated position rather than a judgement that clearance is required.

The relevant question is the clinical decision support exclusion under the 21st Century Cures Act, which turns substantially on whether the clinician can independently review the basis for a recommendation. The product's design points toward the exclusion: responses are described as always sourced and cited, grounded in peer reviewed medical literature rather than in an unverified general corpus, and the retrieval augmented approach the founder published exists precisely to anchor generative output to identifiable sources. A clinician who can see which paper an answer came from is in the position the exclusion contemplates.

What is not published is the company's own view. Buyers should ask it to state its regulatory position in writing, and should ask separately about the direct to clinician mobile application, since a tool used by an individual clinician outside any institutional governance sits differently from the same intelligence delivered under a health system's controls.

Two governance commitments stated that most peers do not make: the platform is stated free of pharmaceutical advertising, a direct contrast with ad supported clinical reference products including one indexed here, and institutional controls are stated to keep health systems in authority over how AI generated intelligence is used. Held back from A because no bias evaluation or third party audit was retrieved.

Two disclosures here are unusual and one of them is unflattering, which is why it counts. Performance is reported against a named public benchmark at a stated task completion rate across a stated number of tasks, and the figure is modest rather than impressive.

Publishing a middling number on a benchmark anyone can run is a different act from publishing a high number on a test you designed: it invites comparison the vendor cannot control and it tells a buyer what the current state of the art actually looks like on this problem. The second is the tool set, which is enumerated rather than described, covering record system functions, a browser, clinical calculators, a code interpreter and the record database.

For an agentic product that enumeration is the safety disclosure, because the tools define what the agent can reach and therefore what it can do wrong: a browser means it can bring in outside content, a code interpreter means it can compute something a clinician will not check, and knowing the list lets an institution reason about the blast radius rather than guessing. Grounding is stated as retrieval from a vector database of peer reviewed evidence rather than unconstrained generation.

Held below the top grade because no warranty, indemnity or remediation commitment attaches and no evaluation exists on clinical tasks in a live setting. Ask for performance on your own specialty's tasks, and what the agent does when a tool call fails.

Electronic health record integration is the central claim in this company's positioning and it is the claim with the least supporting detail. Almanac describes itself as a trusted intelligence layer embedded in record environments rather than a standalone chatbot, and states that it is designed to work within existing systems and to integrate record data.

No electronic health record is named. No integration standard is identified, and nothing indicates whether the connection is built on the modern interoperability standards a health system would expect, or on a proprietary route. No integration documentation, developer material or application programming interface reference was located, and no live integration at a named institution is described.

The distinction matters more here than for most vendors, because being embedded rather than standalone is the differentiator the company leads with. A buyer should ask which records are supported today as opposed to on a roadmap, what the integration mechanism is, what data the platform reads from the chart, and whether any institution is running it in production. Graded C on evidence rather than on intent.

No deployment model, hosting arrangement, cloud provider, implementation timeline or data residency commitment was located, and no customer institution is named.

Two distribution routes are nonetheless visible and they carry materially different governance, which is the useful observation on this axis. The company sells an enterprise proposition governed by institutional controls and embedded in the electronic health record. It also publishes a mobile application for healthcare professionals through a consumer application store, offering coverage of more than a million medical topics across over a hundred and fifty specialties.

Those are not the same product relationship. In the first, a health system contracts, reviews and governs the deployment. In the second, an individual clinician installs software on a personal device with no institution in the arrangement at all, and the institutional controls the enterprise pitch rests on are absent by construction. Nothing published explains how the two relate, whether they share infrastructure, or what governance applies to the individual route.

Buyers should establish which product they are actually buying, and health systems should ask whether their clinicians are already using the individual version.

No pricing is published for either the enterprise platform or the mobile application, and no pricing unit, tier structure or contracting model is described.

One element of commercial transparency here is genuine and unusual enough to credit, even though it is not a price. The company states repeatedly and prominently that the platform operates free from pharmaceutical advertising, and its investors frame this as aligning incentives with clinicians and patients rather than with promotion. That is a disclosure about the revenue model rather than about the revenue, and in this particular category it carries real weight: clinical reference and point of care products have a long history of being funded by pharmaceutical promotion, and a buyer evaluating an evidence tool has a legitimate interest in knowing who pays for it. Stating what the business model is not is a partial answer to a question most vendors leave entirely unaddressed.

The funding position is also public, with a ten million dollar seed round in April 2026 led by named investors and total funding of roughly twelve million.

What remains absent is the price and the unit. Buyers should ask whether the product is licensed per clinician, per organisation or per query, whether the mobile application and the enterprise platform are priced separately, and what happens to individual users if their institution declines to contract.

Coverage is quantified rather than merely asserted, which is what carries this above the bottom band at an early stage. The published application describes more than a million medical topics across over a hundred and fifty medical specialties and around a thousand conditions and treatment approaches, with content drawn from peer reviewed journals. The stated ambition spans primary care through to highly specialised fields, and the product proposition is explicitly about bringing specialist grade knowledge to clinicians who are not specialists, which is a coherent and specific position rather than a general claim of breadth.

Held at B because the coverage described is of content rather than of deployment. No care setting is characterised, and nothing distinguishes how the product behaves in an emergency department, a primary care clinic, an inpatient ward or a rural practice with limited connectivity. Clinical validation is stated to be underway in academic medical centre settings, which is a narrow and well resourced slice of the settings the specialty breadth implies.

Buyers outside the academic centre should ask which settings have been validated, and whether coverage depth is even across those hundred and fifty specialties or concentrated in a few.