The breakthrough of the assembly line was not that machines became intelligent. It was almost the opposite. You could make a process efficient by deciding the route in advance: a part entered at one end, each station did one predictable thing, and the next station was always known. Repeat that sequence often enough and you reach a scale that had not been possible before.
That logic eventually became software architecture, and ETL is one of its purest expressions. ETL stands for extract, transform, load: pull data out of one system, reshape it according to rules somebody wrote in advance, and load it into another. It is how most companies move data between their systems on a schedule, and the path is defined before the data arrives. The better you specify the path, the more reliably the system runs. That model is still useful. It is also a strange model for much of knowledge work.
Consider the difference between a car moving down an assembly line and a self-driving car moving through a city. The assembly-line car follows a route someone else defined. The self-driving car has a destination, but nobody can specify every action it will take before the trip begins. A pedestrian steps into the street. Construction closes a lane. The vehicle has to observe the situation, decide which signals matter, apply the rules and objectives it has been given, and act. The route emerges from context.
That is what we are asking AI to do inside organizations. A sales leader says, “Figure out which opportunities need attention and take the next step.” A finance leader says, “Figure out why this account has not paid and do what we normally do in this situation.” These sound like workflows, but the interesting part is precisely the part you cannot enumerate ahead of time: the AI has to decide what information matters, retrieve it, understand it in the context of how this organization works, reason about the situation, and act through the right systems.
I think that pattern needs a name.
RARE: Retrieve, Augment, Reason, Execute
RARE is an AI integration pattern:
Retrieve the live system state relevant to the task.
Augment it with the organizational knowledge needed to interpret that state.
Reason with an AI model about what should happen.
Execute the result through APIs.
Or, more compactly:
API(s) → Retrieve → Augment → Reason → Execute → API(s)
The easiest contrast is this:
ETL follows a route. In RARE, AI chooses the route using live data and organizational knowledge.
That does not make RARE a replacement for ETL. If you need to move ten million rows from one system to another every night, use ETL. Determinism is a feature when the problem is deterministic. RARE is for the other class of work, where what should happen next depends on meaning, context, and judgment at runtime.
Retrieve: get what matters now
Suppose our sales leader asks the AI to review ten opportunities. The naive approach is to hand the model the CRM records and ask it what to do. But one opportunity had a demo yesterday, another has been silent for three weeks, a third just opened a serious support ticket, and one prospect said on a call that procurement will not begin until next quarter. The relevant state is scattered across CRM records, email, call transcripts, support systems, calendars, and product analytics, and the same information is not relevant to every opportunity. For one account, yesterday's email determines the next action. For another, the open support ticket dominates everything else. For a third, a pricing exception discussed six months ago suddenly matters again.
So retrieval cannot mean “fetch a fixed bundle of fields.” The model has to work out what is likely to matter to the situation in front of it, retrieve that, and retrieve more as its reasoning exposes new questions. Retrieval is part of the intelligence loop, not the plumbing before it.
Augment: APIs know what happened, not what your organization means by it
Live system state is only half the problem. The CRM says an opportunity has had no activity for fourteen days. Is that bad? Maybe. Or maybe the company’s sales process says that once procurement begins, the account is left alone for three weeks. Perhaps this type of customer must receive legal language before a follow-up. Perhaps the company learned last month that a particular pricing objection should be escalated rather than negotiated by the rep.
None of that lives in the CRM. Augment means adding the organizational knowledge needed to interpret the live state: qualification rules, positioning, escalation policy, pricing guidance, runbooks, ownership rules, brand voice, and lessons learned from previous corrections.
An API can tell an AI what happened. It rarely tells the AI how this organization wants that situation handled, and that gap is the difference between an AI with access to company software and an AI that can work like the company.
Reason: the model is the intelligence
RARE does not require a new kind of reasoning engine. The model reasons. That matters because infrastructure around AI is sometimes described as though the middleware itself were the agent. It is not. Given the relevant live state and the right organizational context, a modern model can read messy evidence, reconcile conflicting signals, and decide what information or action should come next.
Reasoning may also send the system back to Retrieve. The model sees that a customer complained about an integration and inspects recent support tickets, or notices a pricing promise in an email and retrieves the contract. So the clean four-stage diagram is conceptual, not a claim that every execution is a single pass. In practice, RARE looks more like:
Retrieve → Augment → Reason → Retrieve more → Reason → Execute
The point is that the model chooses what matters and what should happen next, rather than a giant predetermined decision tree.
Execute: reasoning has to leave the chat window
A lot of AI architecture ends just before the useful part. The model gives you a good answer, and then a person copies it into Salesforce, sends the email, opens the Jira issue, updates the invoice, or notifies the team. RARE includes execution because the value of reasoning about work is eventually doing the work: sending the message, updating the CRM, creating the issue, adding the finance record, scheduling the meeting, escalating the incident.
This is also where identity, credentials, permissions, approvals, and auditability become important. Those are not additional letters in RARE. They are what executing RARE safely inside a real organization requires.
The same pattern appears everywhere
Sales is an easy example, but RARE is not a sales architecture. In operations, an AI might retrieve a ticket, customer history, and SLA state; augment that with escalation policy and ownership rules; then update the ticket, notify someone, or create a task. In engineering, it might retrieve an error, deployment history, and incident state; augment those with runbooks and ownership knowledge; and create an incident or start an approved remediation. In finance, it might retrieve an invoice, payment history, and contract; augment that with collections rules and exception policy; and update the record, draft outreach, or route an approval. Marketing and product follow the same shape: retrieve the evidence, augment it with positioning or product principles, decide whether a signal matters, and act in the system that owns the record.
Traditional automation is excellent when every branch in these examples can be specified ahead of time. RARE matters when they cannot.
The hard problem is not similarity. It is relevance.
At first glance, modern retrieval makes this seem easy: embed everything, find the closest documents, stuff them into the context window. But “similar” is not the same as “relevant.” The CRM might contain hundreds of fields, email years of messages, and the company thousands of pages of internal guidance. Throwing all of it at a model is not intelligence; it is avoiding the selection problem.
Most knowledge work only rhymes with something done before. Suppose last month a late-stage opportunity had an unresolved support escalation, and the right move was to understand the support problem before sending another sales email. The lesson should not become a rigid rule saying, “Always retrieve support tickets for opportunities.” The useful lesson is subtler: support history may become highly relevant when a similar risk appears. The AI should recognize that relationship in a new situation and pull the information that matters now.
This is not a new problem in AI. Russell and Norvig discuss learning using relevance information in Artificial Intelligence: A Modern Approach: prior knowledge can tell a learner which attributes matter to the target and which can be ignored. Stuart Russell’s earlier work on analogy makes a related point. Superficial similarity is not enough; the similarities relevant to the inference are what matter.
RARE is not retrieval by similarity. It is retrieval guided by relevance.
References: Russell & Norvig, Artificial Intelligence: A Modern Approach; Stuart Russell, “Analogy by Similarity”.
Isn't this just a Skill?
Sometimes. If a task repeats cleanly, a Skill is the right abstraction: retrieve these records, consult this guidance, call these tools, produce this output. But Tuesday's problem is rarely identical to Monday's. The customer is different, the evidence is different, and the relevant part of the company's knowledge is different. The unusual wrinkle is often exactly what makes the task worth giving to an AI instead of conventional software, and there is no Skill called “handle this weird combination of circumstances.”
Skills encode reusable procedures. RARE handles partial repetition.
The AI can reuse patterns from prior work without requiring the current situation to match a predefined workflow exactly, and those patterns help it decide what context to retrieve. A Skill can certainly encode a RARE-shaped procedure, but the Skill is the recipe, not the kitchen: the live system connections, organizational knowledge, identity, credentials, execution surface, and controls still have to come from somewhere.
There is an older AI lineage here too. Classic case-based reasoning describes systems that retrieve relevant prior cases, adapt them to a new problem, revise the result, and retain what was learned. The intuition is the same: intelligent work usually means adapting experience rather than replaying an exact script.
Isn't this just MCP?
No, though MCP is an important part of the stack. It standardizes how an AI client discovers and calls tools and accesses context, which solves a real interface problem. But exposing a Salesforce tool does not tell the model when Salesforce is relevant. Exposing Gmail does not tell it which thread matters. Exposing Jira does not tell it whether this situation should become an issue. And exposing all three does not tell the model how this organization handles the situation in front of it.
So I would separate the layers this way:
MCP gives AI tools. Skills encode known procedures. RARE describes the work pattern that dynamically assembles context, reasons, and acts.
RARE can use MCP. It can use Skills, REST APIs, SDKs, or internal APIs. Those are complementary pieces, not competing acronyms.
Then the AI gets it wrong
Now imagine our sales AI has done almost everything correctly. It sees that an opportunity needs attention, retrieves the right email thread, notices a recent meeting, applies the company's sales guidance, drafts a good follow-up, and updates the CRM. But it forgets to update the next-step date, and the sales leader corrects it:
“Whenever you change the next step, update the date too.”
There are two ways to read that correction. The first is that the AI made a mistake and a human fixed one CRM record. The second is that the organization just learned something about how it wants this type of work performed, and the next related task should benefit from it.
RARE+C: close the correction loop
RARE is the core execution pattern. RARE+C is RARE plus Corrections.
The plus sign is intentional. Correction is not a fifth serial step after Execute. It is a feedback loop around the whole process.
RARE → outcome / human correction → Knowledge → better next RARE loop
A correction can land anywhere in that loop. It might teach the system to Retrieve another source in similar situations, add knowledge that should Augment future context, change how the model Reasons about a particular pattern, or constrain how the system Executes the resulting action. What makes it work is that the lesson lives in context, with no model retrain and no brand-new Skill every time somebody notices a mistake.
The mechanism is not speculative. Reflexion showed that agents can turn task feedback into textual reflections stored in episodic memory, then reuse those reflections as context on later attempts, improving decisions without updating the model weights.
Reference: Shinn et al., “Reflexion: Language Agents with Verbal Reinforcement Learning,” NeurIPS 2023.
For organizations, the interesting version is not one agent remembering one failed attempt. It is corrections becoming durable organizational knowledge, available whenever they are relevant to future work. That is where AI starts to feel less like a stateless assistant and more like a system that learns how the organization operates.
One boundary is worth stating plainly: recognizing every failed execution, deciding what lesson should be learned, and safely promoting it into shared knowledge is a harder problem than storing a correction, and human review still matters. RARE+C describes the feedback architecture we want, not a claim that every correction can be generalized automatically.
The infrastructure sandwich
Once you accept the RARE model, an implementation requirement falls out of it. The model needs infrastructure on both sides of the reasoning step: access to live systems and relevant organizational knowledge before reasoning, and the ability to act through real APIs under the right identity, credentials, permissions, and approvals after it. For RARE+C, corrections need somewhere durable to live. For HexaHQ, that looks like this:
API(s) → HexaHQ → AI model (+ Skills) → HexaHQ → API(s)
On the way in, HexaHQ gives the model access to live APIs and organizational knowledge, and lets it retrieve more as its reasoning reveals what matters. The model reasons. On the way out, HexaHQ exposes the capabilities needed to act through the appropriate APIs and handles the execution infrastructure around them. When someone teaches the AI something durable (a correction, a rule, a preference about how the organization works), that knowledge is available to future runs when relevant.
HexaHQ is the infrastructure around the reasoning step.
HexaHQ is therefore not the reasoning engine, and that distinction has consequences. Better models make RARE systems better. Different AI clients can participate in the same organizational context. The integration layer does not need to own the intelligence in order to make that intelligence useful across the systems where work actually happens.
From assembly lines to adaptive work
The assembly line did not make factories obsolete. It made one class of work far more efficient by exploiting repetition and predictability, and ETL and conventional workflow automation did the same for software. They remain the right tools for processes whose routes can be specified in advance.
AI makes a different class of automation practical. You can give the system a goal without knowing every step it will need to take. It retrieves the state that matters, augments it with the way your organization works, reasons about a situation it has not seen exactly before, and executes. When it is corrected, that correction makes the next related decision better. That is RARE, and when the loop learns from its mistakes, that is RARE+C.
If ETL is the assembly line for moving data through predetermined processes, RARE is closer to the self-driving car: the destination is known, but the route has to be worked out from the world as it actually is. The infrastructure for knowledge work is starting to make that same transition.