Intro to Providio OS
Inside Providio OS: The Harness Behind a Revenue Decision
Sai & Sanjay
Share
- NEWSCompetitor X launches spring sale, Dallas to Las Vegas from $89
- FARECMPX DFW-LAS Y $119 → $89, travel Mar 3 to Apr 15
- BOOKDFW-LAS bookings pace −9% vs last week
Every morning, hundreds of thousands of signals reach your airline's commercial teams, and each team reads them in its own tools before meeting to agree on a response. The dashboards are current but the decisions are late, and that gap is the coordination tax every complex enterprise pays.
We built Providio OS to end it, with a harness at its core that gives our foundation model the context, memory, tools and controls to turn signals into decisions a person can approve, delegate or automate. What your airline teaches that model never reaches another customer. Providio OS is the world's first harness for high-stakes revenue maximization, running on the world's first foundation model built for every airline, from ULCCs and LCCs to network and international carriers. This is part one of two. Part two shows how it matches or beats every published leader on Sierra's τ²-bench, at about half the cost of the airline leader.
Who is asking, and as of when
Give the last few years their due. Long context windows let a model read a whole situation in one pass. Retrieval grounds answers in a company's own documents [2]. Memory lets an assistant remember the person it works for. We use all three, and each one is enough to answer a question. None of them is enough to make a commercial decision inside your airline, because none of them answers the two questions every good operator asks before acting: who is asking, and as of when?
We learned that in our own early versions. The context did not know when it was true. Retrieval returns the passage most similar to the question, which is not always the passage that is correct today. Last quarter's fare-matching rule reads almost exactly like this quarter's, so a similarity search returns either one, and when two documents disagree the model blends them into an answer that neither document supports.
The context did not know whose it was. Remembering one person is helpful, but an airline has many teams whose rules legitimately differ. Paid search wants to push a promotion the moment a competitor's sale goes live, while email is holding the same promo code for its weekly send. Both rules are right for their own channel, and the director who oversees both teams needs to see both.
More context made answers worse and more expensive. Loading everything the company knows into every call means paying for the same tokens again and again, and it hurts accuracy, because models miss details that sit in the middle of a long prompt [1]. We learned something about checking work too. Ask one model to review another's draft and it mostly judges whether the draft sounds reasonable. A persuasive but wrong draft talks its way through.
So we built the harness around those two questions. Every piece of context in the harness carries where it came from, which part of your organization it belongs to, and the period it is true for. Each task gets only the context it needs. And code, not a model's opinion, decides what is allowed to act.
The harness at a glance
Figure 1 reads top to bottom. Raw signals distill into facts, which link into a context graph. A role-access gate decides which part of the graph each person's agents may read. A router sorts each request and sends real work to a planner that long-term memory primes. The planner acts through tools, sub-agents and loops, keeps its short-term memory on a budget, and proposes a change that has to pass a write gate before anything outside the harness moves. Every step is logged, and overnight the gardener folds that log back into the graph. The seven sections below each take a close-up of one part.
From raw signals to facts and understandings
Everything starts as raw context: operational tables, competitor fare feeds, playbooks, contracts, notes from past decisions and ordinary conversations between colleagues. None of it goes to a model as it is. The harness distills it into two kinds of records.
A fact is a small claim with a source. Each fact ties to the thing it describes, the period it applies to and the exact passage it came from. "Competitor X cut its Dallas to Las Vegas fare to $89 for travel from March 3" is a fact, and it keeps a link back to the memo line and the fare-feed row it came from. An understanding is a pattern that holds across many facts: a rule, a tendency or a cause. "On this route, matching a competitor's fare within two days keeps bookings steady" is an understanding. No single document states it, so we keep a link to every fact that supports it.
Both are about entities, the things the business deals with every day. Some are easy to pin down because everyone already agrees what they are: a route code, a fare class, a campaign ID. Others have to be worked out from context. A memo that says "Dallas" could mean Dallas/Fort Worth, DFW, or Dallas Love Field, DAL. The harness links the mention to both airports with a confidence score and keeps the link reversible. As evidence arrives the score moves toward one airport until the link settles. Figure 2 plays both steps on a short memo.
The context graph
Linked together, facts, understandings and entities form a context graph. Revenue management, marketing and network planning each work mostly in their own region of it, and the regions overlap, because the teams share the same routes, the same seasons and the same competitors while trying to steer the ship as one team. A fact that sits in an overlap is written once and read by every team that needs it. Without the graph, that fact gets pasted into each team's prompts and documents, and the copies drift apart. With it, three teams bring the same number to the planning meeting.
The graph grows every day as new signals arrive and link to what is already there. When an agent asks a question, it pulls only the part of the graph that answers it, and because every node keeps its source, an agent that needs a detailed summary lost can go back to the original text. Figure 3 shows a simplified version.
Keeping the graph true: the gardener
A graph that only grows will eventually contradict itself. The gardener is a background process that runs frequently and keeps the graph true, the way a good librarian walks the stacks. It admits new facts and understandings, merges duplicates, settles entities like "Dallas" once the evidence is clear, and reads the record of the day's conversations and decisions to prepare the context each role is likely to need tomorrow. Its hardest job is disagreement, which comes in three kinds.
Sources disagree. A revenue contract says the holiday blackout runs December 20 to January 3, while a marketing playbook says December 22 to January 2. The gardener does not average the dates or quietly pick one. It raises the conflict to a person, uses their choice as the value every agent sees, and keeps the other source on record.
Roles disagree. Email holds promo codes for the weekly send, while paid search wants to push the same promotion the hour a competitor's sale goes live as the pricing team is busy increasing ancillary fares for the affected flights not knowing about the competitor marketing activities. All actions may be right for their channel, so the gardener does not merge them. Each rule stays in its own lane, and the two meet only when someone who oversees both teams decides they should.
Time disagrees. Every fact carries the period it applies to. When "match competitor fares within 72 hours" gives way in October to "match within 48 hours", the older fact is marked replaced rather than deleted, so an agent can still answer as of an earlier date and an auditor can see what the rule was when a past decision was made. When two windows overlap, say a regional playbook arrives late and still says 72 hours, the gardener treats it like a source conflict and raises an open question.
How people resolve these conflicts becomes memory too. The next time a similar one comes up, the person deciding it can see how your organization handled it before. Figure 4 zooms into the graph during one overnight pass.
Role access: who sees which part of the graph
A context graph that covers a whole company is only useful if each person's agents see the right parts of it. The first of the harness's two gates is role access, and code enforces it, not a model's judgment.
Context is layered the way the company is organized. The outer layer holds what is true for the whole organization. Inside it sit layers for a function such as revenue management, then for a role such as pricing analyst, then for the task in front of them. Each layer inherits the layers around it, so house rules are written once at the organization level and never repeated, and a new analyst's agents follow the company's rules on day one with their whole context budget left for the work. Nothing that runs after the gate can widen what the gate let through.
Figure 5 applies the gate to our task. A pricing analyst's lane covers competitor fares, promotions and fuel, so the task pulls in the fare, the matching rule and fuel cost. Paid search reads auction insights, campaign results and search demand. Email reads engagement and list fatigue, none of which bears on a fare decision, so this task takes nothing from that lane. Revenue Management is concurrently able to use marketing competitive signals into pricing adjustments. E-commerce is able to simultaneously facilitate landing page creation, tagging and integration. Managers, directors, VPs and the C-suite sit above the lanes and, by design, see all of respective context and the human-in-the-loop decision executions of their teams as the work happens instead of waiting for Monday's deck.
Just enough context for each task
Role access decides what an agent may read. Memory decides how much of that it actually carries into a task, and memory has two parts.
Long-term memory is the durable record built from the graph. At the start of a task it primes the agent with the rules that apply to its role, the recent decisions related to the task and any questions still open, and during the task the agent recalls more when it needs to. That replaces the habit of pasting everything into the prompt up front.
Short-term memory is the working set each agent carries through the task. It stays within a fixed budget, so a long investigation doesn't drown in its own tool output. In our example the competitor's fare and the 48-hour rule stay pinned through the whole investigation.
Figure 6 runs the same task both ways. Without a harness, the agent re-sends the organization, its function, its role, the history and the tools on every call, and the context keeps growing. With the harness, the agent is primed once and its working set stays inside the budget, at a fraction of the context per call. Answers come back faster, cost less, and the agent is a lot harder to confuse. You see it in the cloud bill and in how quickly an answer lands.
From question to proposal: the router, the planner and its helpers
Work starts with a request. Usually an operator asks a question in chat, and sometimes a signal raises one on its own. A router classifies each request first. A simple question, today's fare on a route, goes straight to one tool and comes back in seconds. Anything that needs real work goes to the planner, and the analyst talks to the planner directly.
The planner's seat belongs to our airline foundation model, tuned to how your airline decides across functions. That is where knowing the business pays off on every single request. Long-term memory primes the planner with the rules for the analyst's role, and it decides what has to happen next without doing the work itself. It acts through a fleet of digital agents of three kinds. Tools look things up or calculate. A fare lookup or a bookings query is plain code and never calls a model. Loops pair an executor with a validator: the executor drafts, the validator tests the draft against the goal, and the draft iterates back to planner until it passes. Sub-agents take a self-contained piece of work with their own short-term memory and hand back a short result instead of all their working. We use three that follow the shape of a commercial decision: a signal agent that confirms what changed, a reasoning agent that explains why it matters, and a decision agent that prepares the change. Each runs on the smallest model that can do its job.
Everything the planner hears, from the question to each tool result, loop outcome and sub-agent report, lands in its short-term memory as it arrives, with the primed rules pinned. When the planner has what it needs, it bundles the working set into a reply and a proposed change, and the proposal goes to the write gate.
In our example, the pricing analyst asks whether to match Competitor X. The planner looks up current fares and recent bookings, then runs a loop that drafts the match and checks it against the rules. The validator sends the first draft back for ignoring the holiday blackout and passes the second. The signal agent confirms the sale and its end date, the reasoning agent prices what waiting would cost, and the decision agent prepares the fare change. In the marketing lane, the same fare cut reaches paid search's agents, who stage a refresh of the Las Vegas promo copy and bids, and both proposals wait on the same approve button. Figure 7 plays the pricing conversation step by step.
The write gate: from a plan to an approved change
No agent has authority by title. Every write to an outside system, a fare update in the pricing system or a budget change in an ad platform, must first pass preconditions written in code. Anything agent activity with possible impact exceeding a set threshold, which we call the blast radius, waits for a human-in-the-loop escalation. Today, agents stage the work. People approve it, every approved change comes with an undo button, and every action leaves a receipt that records who approved what, on which facts, and when.
The receipts do two jobs. They join the turn log, so the gardener folds each decision back into the graph and the next one starts with what the current agent execution learned. And this decision iteration output is refined for what leadership sees: every open signal and every staged change across every function, who approved it and on what evidence, as it happens.
So, back to that morning we started this post with. The signals will keep coming, faster every year. What changes is who reads them, how quickly a decision follows, and whether your whole team can see why it was made. Not another dashboard. Not a copilot that impresses. A harness that executes, with a person on the approve button. Analysts stop copying numbers between tools and spend the morning on the calls only a person should make. That is what Providio OS is for.
In part two, we open the harness up and walk through the optimizations underneath and what they did to the scores.
[1] N. F. Liu et al., Lost in the Middle: How Language Models Use Long Contexts, TACL, 2024. arXiv:2307.03172.
[2] P. Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS, 2020. arXiv:2005.11401.
