Picture the default enterprise AI stack.
Source systems pour into a warehouse. A CRUD app gets built so people can read and edit it. A dashboard goes on top so leaders can scan for outliers. Reports get generated. Eight months in, someone gets around to the question that funded the project, and an agent gets bolted on top of the dashboard with the same data underneath in the same shape, presented the way the humans were going to read it.
The mistake is sequencing. The agent shows up last in a stack designed for a different reader.
Each preceding layer was built for a human
Look at what the legacy stack assumes about its audience.
A CRUD app assumes a human will navigate it. Forms scan by eye. Lists paginate. Filters tune for three-second decisions. A dashboard assumes a human will look at it. Red-yellow-green because humans process colors faster than numbers. KPIs above the fold because humans don't scroll. A report assumes a human will read it. Section headers, narrative, an executive summary at the top because the executive isn't going to read the bottom.
Each layer is a translator. Raw data into human-shaped tables into human-shaped charts into human-shaped narrative. By the time you bolt an agent on, it's being asked to read a translation made for someone else.
The agent doesn't need any of this. Give it a graph and it can hop edges. Give it a typed schema and it can compose queries. Give it a context graph and it can build a story. You're showing it the slide deck and asking why it can't reason about the underlying business.
The reframe is the audience, not the intelligence
The instinct most teams bring to "agent on legacy stack" failures is the agent isn't smart enough yet. That's diagnostically backwards. The frontier models are smart enough for almost any single-job ask. Agent-on-top fails because the agent is reading a stack built for someone else.
Once the agent is the primary reader, the architectural unit changes. The legacy stack's unit is the table: rows and columns of fact. The agent-first unit is the dimension: a named scope of concern with the judgment patterns of an expert who works inside it.
A table tells you what's in inventory. A dimension tells you what an inventory expert worries about: stockouts on critical SKUs, slow-moving deadweight, the seasonal patterns that mean this November dip is normal but that one isn't. The agent reasons against concerns. The table is what the dimension reaches into when it needs evidence.
You don't get rid of the table. You stop building everything else for the table.
The legacy pieces, refocused around the context graph
Agent-first doesn't mean tearing out the warehouse, the CRUD app, and the dashboards. It reorganizes what each one is for.
The new center is the context graph: a graph of typed scopes (dimensions, work orders, artifacts, decisions) the agent reasons against. The warehouse becomes infrastructure the graph reaches into when it needs evidence.
CRUD stays, but as authoring. Some facts can only be set by a human declaring them: the customer's preferred shipping address, the contract value, the project phase. CRUD is where humans set intent; the agent does the finding. The agent sits on top of the CRUD app, not the dashboard.
Dashboards stay, but as audit. You shouldn't have to hunt through a BI tool to find a red row. The agent lives in the data and surfaces it the millisecond it appears. The dashboard becomes a place to check the agent's work at scale: system health, output volume, drift over time.
The trap: chat-on-a-database
The first instinct most enterprises act on is to put a chat box over the existing schema, hand it to an LLM that can write SQL, and call it agent-first. Now you can ask your data anything. It demos beautifully and breaks in production.
The trap has a specific shape. A legacy schema is full of technical debt and missing the why: foreign keys that don't enforce, columns whose meaning shifted three migrations ago, statuses that look enumerable but carry process semantics nobody wrote down. The agent writes a query that's technically correct and operationally useless.
We see this repeatedly. "Ask your warehouse anything" turns into "the agent kept saying margin was healthy when we knew it wasn't." The query was right against a schema that no longer matched the business.
The fix is a layer that captures the meaning the schema lost: a context graph linking facts to concerns, work orders to artifacts, decisions to their rationale. The chat box doesn't make an agent-first system. The graph behind it does.
[!NOTE] We have a name for this internally: understanding precedes structuring. You don't add the agent and pray the structure holds. You build the structure (the dimension graph) so the agent can do anything at all.
A worked example: the MOR that disappeared
One of our customers is an aerospace fastener manufacturer. Every Monday morning, site analysts open a 50-tab Excel workbook called the MOR ("Management Operating Review"), spend roughly four hours pulling data from the ERP, cleaning it, and dropping it into the workbook. The workbook feeds a PowerBI dashboard. The executives open the dashboard and scan for "red": work orders where the margin came in below plan.
Classic legacy stack: data → workbook → dashboard → human scanning for red.
When we first met this team, their AI integration was uploading the workbook into our platform. The same 50-tab Excel the analysts spent four hours assembling was being fed to myai, which summarized the variances back out. It worked. It was also exactly the wrong shape: a human-shaped output, paying the four-hour assembly tax to produce it, then handing it to a non-human reader. The agent was reading translations of translations.
The right move was to skip the workbook. If the agent is the reader, why build a workbook for a human first?
When we asked the team what made a margin variance worth investigating, the answer was never on the dashboard. The dashboard told them which work order. The team's experience told them why: copper spikes, lot-size splits, expedite freight, the customer who runs a tighter spec than the others. None of it was on the screen.
We built a Margin Protection dimension. Its job, in plain English: worry about gross margin on completed work orders. It scans the ERP for any closed work order under plan margin and carries the team's tribal knowledge as judgment patterns. When the trigger fires, it materializes a single artifact: a Margin Variance canvas for that work order, already populated with the bill of materials, the original quote, the procurement timeline, and the relevant judgment ("copper rose 12% over the quote period; this accounts for ~80% of the variance"). It tags the procurement lead and cross-references prior similar variances on the same customer.
The dashboard didn't get smarter. It disappeared. The exec's PowerBI tab still exists, but it's audit now: how often the dimension fires, what it caught, what it missed. System health, not the work itself.
The team got back four hours every Monday. They also got something they didn't have before: the variance came with the why attached. The "what" had been on the dashboard for years. The "why" had been in three people's heads.
What to do Monday morning
If you've defaulted to the legacy sequence (data, CRUD, dashboard, agent-on-top), change the order in which you build, not what's there.
- Pick the role. A site controller, a planner, a quality engineer. Not "the company." A specific person with specific concerns.
- Map the dimensions. What does that person worry about, in named scopes? Margin protection, schedule risk, supplier reliability. Three to seven, usually.
- Locate the data each dimension reaches. The dimension knows what to ask for; the warehouse knows where it lives. The graph between them is the work.
- Identify the triggers. What event should cause the agent to speak without being spoken to? A margin under plan. A schedule slipping. A supplier missing a commit. Triggers turn passive scopes into active ones.
- Build the surfaces last. A canvas. An email when the variance lands. A weekly digest. Surfaces materialize on demand against the dimensions you've already built.
The agent isn't the last reader of your data. It's the first. Build for that reader, and the rest of the stack reorganizes around it.
That's what we're building at Make Yourself AI.