A photo of a cracked housing and a short written note should point to the same history. So should a complaint written in German and the English corrective action that closed a similar case years earlier. In a quality system, that match is the difference between starting from institutional memory and starting from a blank page.
Octave builds Reliance, a multi-tenant quality system. Complaints, corrective actions, procedures, and audit records are supposed to stay inside the customer they belong to. AWS’s October 20 case study, How Octave built a secure multi-tenant AI foundation on Amazon Bedrock, describes Octave building that shared, tenant-isolated layer first, and only then putting one assistant into production: complaint summarization and triage.
The records are the product, and the risk
The case study says Reliance supports more than 650 enterprise customers and more than 40 applications. Across that estate, Octave says, sit more than 2 billion documents: Word files, PDFs, scans, spreadsheets, images, email.
Keyword search fails this corpus in a boring, expensive way. Similar defects do not share wording. A photo does not share a vocabulary with a procedure. A corrective and preventive action (the record of what was fixed, and why) may not even share a language with the new complaint. People reinvestigate problems the organization has already paid to understand.
Those same records are the ones you cannot mix. Each customer is a separate tenant. A missed search wastes an afternoon. A search that crosses a tenant boundary is a disclosure. If you are buying AI for quality, audit, or other customer-confidential work, that constraint should scare you more than the logo on the model card. Which model actually sits on the path is still a gap in the account, and it matters if you are comparing cost or behavior. Swapping the logo would not fix a shared key over customer records.
Build the floor before the first room
The sequencing is the part worth stealing, and the part worth arguing with.
Octave built shared infrastructure before it shipped a pile of vertical features. Complaint triage was the proof, not the platform. Forty-plus applications, each with its own documents and workflow, will otherwise each reinvent embeddings, identity, and content controls. The business case for AI automation here is reuse, not a smarter sidebar. Octave says the shared foundation cut deployment time per use case by 50 percent.
That 50 percent is Octave’s accounting, relayed by AWS, not an independent audit. Hold it that way. Foundation-first also has a cost. The first visible win arrives later, and leadership has to fund plumbing while competitors demo a sidebar. The bet pays only if later workflows inherit the hard parts. Whether isolation and throughput still hold once this pattern spreads across more of those 40-plus applications is an open question, not a result.
One vector space, and a storage number you should not generalize
An embedding is a numeric fingerprint of meaning. Similar problems land near each other even when the words, the language, or the file type differ. The case study says Octave used Cohere Embed v4 on Amazon Bedrock so text and images could share that space across languages. The examples are concrete: a photo of a cracked housing sitting with a written description, and a German complaint lining up with an English corrective action. That removed a separate image pipeline and a separate translation pipeline, two places a document can quietly fall out of search.
AWS’s model documentation confirms the capability was available. Embed v4 accepts text and images, including interleaved page-like content. Allowed output sizes are 256, 512, 1, 024, and 1, 536 dimensions. The default is 1, 536.
The storage choice is more interesting than the model name. On its own representative production queries, Octave says 512 dimensions held its target accuracy and cut storage by about 66 percent versus that default. The width math is almost too neat: 512 is one-third of 1, 536, so about two-thirds of the vector width disappears. That is a comparison of vector width, not a cleaned-up bill. Index overhead, metadata, and the rest of an OpenSearch cluster do not shrink just because the vector got shorter. Do not promote this to a public benchmark. “Target accuracy” has no published score, and a result on one retrieval workload is not a result on yours.
Throughput came from packing, not from a story about a bigger cluster. AWS documents Embed v4’s context as up to roughly 128, 000 tokens per document. Octave packed chunks of roughly 4, 000 tokens into those requests. Divide 128, 000 by 4, 000 and you get a theoretical ceiling near 32 chunks per call. The case study does not claim that. It says packing cut embedding API calls for a large corpus by about an order of magnitude. Roughly ten times, not thirty-two.
A window is a ceiling, not a packing slip. Batch caps, request-size limits, and overhead mean calls were not filled to the brim. AWS also caps a single Embed v4 call at 96 inputs and about 20 MB, so the token window is not the only limit. Treat the tenfold cut as Octave’s measured result, not as 128, 000 divided by 4, 000.
Two other rates sit beside that claim, and they are not the same measurement. In internal testing, Octave reached 28 million tokens per minute. After batch-size tuning with Cohere, Octave says the pipeline sustained 1.4 million documents per 24 hours per tenant workload, a load shaped like one customer’s, not a platform-wide daily total. You cannot convert tokens per minute into documents per day from the published account. Packing is how calls are sent. Chunk size is what you search. AWS’s Embed v4 guidance also notes that smaller chunks often improve retrieval and cost. Those are separate decisions, and Octave has not published the curve between them.
The fingerprints live in Amazon OpenSearch Service, in a separate index per customer, according to the case study. Chunks carry tenant, language, document type, and source-application metadata. That metadata is not decoration. It is part of how a query is supposed to stay inside one customer’s history.
Do not leave isolation to the next feature team
Application checks are how cross-tenant bugs happen. Someone adds a tool, forgets a filter, and a shared service role does the rest. The case study says Octave pushed isolation below feature code.
Each agent session runs in a dedicated microVM: its own processor resources, memory, and filesystem. When the session ends, that machine is stopped and sanitized. Think of a hotel room stripped between guests, not a shared desk. Credentials are limited to that agent and that session.
Amazon Bedrock AgentCore is not one checkbox in this account. The write-up bundles the isolated session, the signed-in user’s identity rather than a shared service identity, and a gateway that authorizes tools, operations, and parameters outside the model. The model can ask. It does not get to grant. Those controls are described together, not as separately tested products. Do not audit them as three proofs the write-up has already pulled apart.
In this design, an AI agent is a short-lived worker with a named user and a fenced index. Reasoning runs on an Anthropic Claude model on Bedrock. The case study never names which one. That is a real gap if you are pricing context, latency, or failure modes. It does not reopen the earlier point: a different Claude model would not repair a shared service role.
The PDF is untrusted. Reading it is still the job
Complaint intake is a pile of other people’s files. Email attachments, scans, images. You cannot refuse them, because reading them is the point of the agent. You also cannot treat them as instructions. Untrusted text is a routine input at this volume. That is not the same as saying successful instruction-hijacking is routine. The case study does not show how often that happens.
The account says Amazon Bedrock Guardrails screen at three points: attachment text, material retrieved from the index, and the final brief. Content that came from an attachment is marked as data, not as an instruction, so a sentence buried mid-document is not quietly promoted into a command. Extraction runs in a sandbox with no outbound network access and no persistence past the session. Personally identifiable information is masked on the way in. Detection and masking rates are tracked per tenant, which means those rates can be measured. It does not mean a buyer or an auditor has been shown them.
Layered controls are a design. Rates are a result. The account does not say how often injections are flagged, what the false-positive rate is, or what an operator sees when a guardrail blocks a brief. Buyers should ask for both.
The same gap shows up when someone has to explain a triage decision. A shrug at the model will not do. The published architecture puts identity, tool checks, and content screening outside the model’s discretion. It does not, by itself, prove that every brief would survive a regulator’s questions. No regulatory acceptance is claimed, and none should be inferred.
What production has actually shown
The Complaint Triage Assistant is in production. Scope, as the case study describes it, is complaint summarization and triage. That is the clean fact.
The write-up does not say how long the assistant has run, how many cases it has touched, or whether it shortened investigations. A live feature is not a measured outcome. Treat it as the first room on the floor, not as proof the floor holds everywhere else.
Questions worth asking before you copy it
- Does a 512-dimension embedding mean quality was sacrificed? Not as a general claim. On Octave’s own representative queries, the case study says 512 dimensions held its target accuracy against the 1, 536 default and cut vector storage by about 66 percent. AWS documents 256, 512, 1, 024, and 1, 536 as allowed sizes. No public accuracy score was released, so do not copy 512 onto a different corpus.
- How does one customer’s history stay out of another’s answer? The case study describes a vector index per tenant, metadata that includes the tenant, a dedicated microVM per session that is stopped and sanitized, and credentials limited to that agent and session. AgentCore carries the signed-in user rather than a shared service role, and its gateway checks tools, operations, and parameters outside the model.
- What stops an attachment from steering the agent? The account says guardrails run on attachment text, retrieved material, and the final brief. Attachment content is tagged as data rather than instructions. Extraction is cut off from the network, and personally identifiable information is masked on entry. Flag rates and false-positive rates are not published.
- Is 28 million tokens a minute the same as 1.4 million documents a day? No. The first is Octave’s internal tokens-per-minute test. The second is documents per 24 hours for a single tenant workload, after Cohere helped tune batch sizes. The two cannot be checked against each other without a chunks-per-document figure the case study does not give.
- What should you demand before copying this? Ask how target accuracy is defined, how long the assistant has been in production, how many cases it has touched, what the guardrail flag and false-positive rates are, and which of the 40-plus applications actually inherited the foundation. A live triage assistant is not the same thing as a proven platform.
The read for anyone funding this
If the demo runs on a shared service role over customer records, you do not have a pilot. You have a disclosure with a loading spinner.
Separate the index by tenant. Scope the session to a person, then destroy it. Authorize tools outside the model. Mark untrusted text as data. Measure retrieval on your own queries before you shrink the vectors to save storage. When someone cites a 50 percent faster rollout, ask what was reused, what was timed, and what has not shipped yet.
A foundation is only a foundation if the next application inherits it without punching a hole through the wall.