The running example in this guide is made up but typical. An equipment rental company with about 180 branches in the US and a dozen in Germany rents everything from scissor lifts to 40-ton excavators. When it signed its first data modernization program three years ago, the goals were the usual ones: get the warehouse off aging hardware, cut the license bill and give the analysts faster dashboards. It hit all three, and the program finished on time.
Then last spring it piloted a quote assistant for counter staff. Within a week the assistant had quoted a 20-ton excavator in Phoenix that had gone out on rent the afternoon before, because availability came from the nightly warehouse load. It also ran through a shared service account, so a counter rep in Dallas could ask for a national account's negotiated rates in every region and get them. Security paused the pilot in May.
We've been building on AWS since 2008, and the last two years of production agent work have changed how we scope every data program. In IBM's 2026 CEO study, chief executives said they expect AI to make 48% of operational decisions without human intervention by 2030, up from 25% today. Each of those decisions draws on a data layer, and the state of that layer decides whether the decision holds up in front of an auditor. Ammar Nizami, a Senior Forward-Deployed Engineer in our Data Engineering practice, sums up where programs go wrong in his data modernization framework: "Most data modernization efforts do not fail at the architecture diagram."
For the rental company, it meant going back over a migration that had already finished and adding what the quote assistant was missing. The assistant needed to know what "available" meant, to check every query against the counter rep who asked, to see where each row came from, and to propose holds and credits through a controlled path instead of writing them itself. Put more generally, it's the work of rebuilding a data platform so software agents can find, understand and act on enterprise data safely, with the cloud migration as one part of it.
The rental company's first program delivered the left column of the table below and almost none of the right, which is how it finished on schedule and still left the quote assistant stuck in pilot.
Because agents use data in a pattern no BI-era platform was built for. One of our Sr. FDEs, Ammar's guide to the lakehouse for agentic AI says it plainly: "Agents query nothing like dashboards do."
The rental company's quote assistant showed all four behaviors in the figure within its first week. A single counter question about a skid steer touched availability, rates, the customer's account terms and the branch's delivery schedule in a few seconds, then went quiet.
At 7 a.m., when the branches opened, those lookups arrived in a burst the warehouse had been sized to serve overnight. Within a month the team wanted the assistant to place holds on machines, and every answer it gave had to respect both the agent's access and the counter rep's.
The quieter problems had been there for years. "Utilization" meant time on rent to the operations team and rental revenue against equipment cost to finance, and the stored procedures that calculated each had no owner.
Nobody could see how old the availability data was. When the auditors asked where a damage charge came from, someone rebuilt the lineage by hand. Analysts had worked around all of that for a decade, but an agent acting on the data at machine speed turns each one into a production incident.
Run your estate through the seven questions below before you approve another pilot. We use a version of this test in the first week of every engagement, and it usually settles the "modernize first or build agents first" argument in one meeting.
The rental company scored 2 out of 7. Its telematics feed carried timestamps, so the age of machine locations was visible, and finance's tables were already in a catalog. Everything else failed, which put it in the bottom band, where the data platform is the critical path and funding more agent pilots burns the budget without reaching production.
The other two bands are more forgiving. With six or seven passes you can put AI agents into production on AWS in read-only mode now and spend the modernization effort on the write path. Four or five usually means a short, targeted program on semantics and access control comes first.
Seven layers, each answering a question an agent will ask at runtime. The figure maps them to the AWS services we deploy most often and to the decision each one forces early, and for the rental company four of those decisions carried most of the weight.
The first was the table format for the telematics and contract history. We'd put both in Apache Iceberg tables, because provenance carried by each row survives compaction, replication and time travel. AWS added Iceberg v3 row lineage and deletion vectors to AWS Glue, Amazon EMR and Amazon S3 Tables in November 2025, so the company can see which rows changed, and when, without a separate lineage tool.
The second was where "available" and "utilization" get defined. If time utilization and dollar utilization both answer to the same word, an agent will pick one and say it with confidence to whoever asked. Defining each entity and metric once and publishing it through the catalog removes the most common source of wrong answers we see in early pilots.
The third was the damage-inspection PDFs the recovery agent would read. Gautham B, a Forward-Deployed Engineer at Mactores, makes the case in an analysis of enterprise AI agents in production: "When lineage, classification and access rules already live in the data layer, retrieval can just inherit them." An index built outside the governed platform, like the SharePoint copy the pilot used, drifts out of policy within weeks.
The fourth was where the credit limits live. In an early prototype of the damage-recovery agent, the cap on goodwill credits sat in its system prompt, and a tester talked it into offering $2,500 on a cracked bucket in under ten minutes. We'd move the $1,000 ceiling, the record-change limits and the token budget into a policy engine at the runtime layer, which turns down anything out of bounds before it reaches the rental system.
Nothing here depends on Redshift, either. Put the company's warehouse on Snowflake or Databricks and the seven layers wouldn't change. On those platforms we usually find the gaps in semantics, access policy and the write path, not in the engine.
As a data-layer problem first, which is why data governance for AI agents has to be designed into the platform from the first sprint. Regulators on both sides of the Atlantic end up asking the same three questions, about who accessed what, on whose authority and how you'd prove it, and if the platform can't answer them for a machine actor, no policy document will close the gap.
Alt text: US and EU compliance frameworks mapped to data-layer requirements for AI agents, with the three questions every regulator asks
For the rental company, that meant PCI DSS for the cards kept on file at the counters, SOX because damage credits flow into reported revenue, and GDPR for customers and machine operators at the German branches. Three practices made it workable.
|
Practice |
What it looked like at the rental company |
|---|---|
|
Generate evidence during the migration |
Lineage, reconciliation reports and access logs came out of the build itself, so nothing had to be re-proved after cutover |
|
Carry the human principal through every call |
Each quote request carried the counter rep's identity as well as the agent's, so the Dallas rep saw Dallas rates |
|
Tier agent actions by reversibility |
Reads ran within policy, credits up to $250 ran with logging, credits up to $1,000 waited for a branch manager, and anything larger went to the claims team |
The same pattern holds where regulation is heavier. Our financial services data modernization work is scoped backward from the examination, on the principle that "The evidence an examiner will ask for is generated while the system is being built." In the KlearTrust agentic claims platform, the agent clears what it can inside its authority and "Clinicians sign off on the edge cases that actually need clinical judgment."
For the German branches, the AI Act's timeline moved this year. The Digital Omnibus on AI, published in the Official Journal on July 24, 2026, pushed the high-risk obligations for Annex III systems to December 2, 2027. The quote assistant isn't high-risk, but a tool that screened job applicants for those branches would be, and much of the logging and data governance it would need overlaps with what GDPR already requires.
There's no credible single number, because price follows the shape of the estate. What we can give you is the list of variables that move the fee, shown below, so you can pressure-test any proposal on your desk. At the rental company, the biggest were the 1,400 nightly jobs feeding the warehouse and the business rules buried in the Oracle rental system's stored procedures.
The quote assistant also showed the run-cost line most business cases skip, which is retrieval and token spend. One question about a single excavator pulled thousands of rows through a loosely defined availability view, and the model was billed for reading every one. After the semantic layer went in, the same answer needed a few dozen. Trimming what an agent reads per call is usually the cheapest saving on the table, though it only works if the catalog can point the agent at the right rows.
|
Model |
Who carries delay risk |
What tends to happen |
|---|---|---|
|
Time and materials |
You |
Scope grows, the date slips, change orders become the norm |
|
Traditional fixed bid |
Shared on paper |
Heavy contingency is priced in, and disputes settle around change requests |
|
Fixed date, fixed fee with absorbed overage |
The delivery firm, for delays inside its control |
The firm only commits when automation has removed most of the uncertain hours |
Data leaders will be asked to spend far more on this layer, and Gartner has put a number on it. At its Data & Analytics Summit 2026, one session's takeaway was that the share of AI spending on AI data readiness will increase 7x between 2025 and 2029. The rental company's CFO wasn't going to approve that as new money in a flat IT budget, and most mid-market and lower-enterprise companies are in the same position, with enterprise complexity and no Fortune 100 cushion to absorb an overrun.
A piece on Oracle and SQL Server modernization to Amazon Aurora makes the funding case directly: "a good part of the AI budget most enterprises think they need is already sitting inside existing IT spend." At the rental company, it sat in the SQL Server warehouse license that renews next spring, the integration tier that bills hours to keep itself alive and an Oracle support contract on a reporting copy nobody had queried in two years. We'd build a three-year total cost of ownership model with those retirement dates in it and treat each retired license as the funding for the next stage.
Four stages, each of which clears a specific class of agent for production. Sequencing matters more than speed here, because an agent that can write to systems should never go live on a platform that can't yet explain its own data.
|
Stage |
What the rental company did |
What it unlocked |
|---|---|---|
|
1. Semantics |
Defined "available", "on rent", time and dollar utilization and customer price tiers, and published them in the catalog |
Agents could find and interpret the data |
|
2. Policy |
Row filters by region and account in AWS Lake Formation, with the counter rep's identity passed through IAM Identity Center |
Agents could read without overreach |
|
3. Retrieval and contracts |
A governed index of inspection PDFs, and a data contract that keeps availability within five minutes of the rental system |
The quote assistant and the utilization copilot went live, read-only |
|
4. Write path |
Credits proposed as structured intents, checked by a validation service and routed by amount |
The damage-recovery agent went live |
Every stage closes with a signed exit and a working slice in production, because a plan that's going to break should break in week three on a proof rather than in month five against a board deadline. Underneath the stages, the delivery work follows a familiar migration rhythm of scoping and committing, proving the riskiest assumption first, building in vertical slices, validating against the legacy system on real data, and then cutting over and retiring. Retiring the rental company's SQL Server warehouse sits inside that plan too, and our Redshift migration consulting runs on the same gates.
Any of the three can work, and the rental company talked to all of them. Which one fits depends on the deadline, how much delivery risk you're willing to carry and how much agentic AI experience your own team has, and the market for data modernization services is full of each.
When the rental company went back to market after the paused pilot, the proposals it got showed most of the warning signs we'd look for before signing anything.
|
Red flag |
How it showed up in the rental company's proposals |
|---|---|
|
A strategy or assessment phase with no working proof |
"Twelve weeks of current-state analysis," with the first working code in month five |
|
Hourly billing with no committed production date |
A rate card and a "target" go-live sometime in the third quarter |
|
Governance scoped as a later phase |
Access control and lineage listed under "Phase 2 (optional)" |
|
No line item for decommissioning |
The SQL Server warehouse still running at the end of the plan |
|
Agents added on top of a traditional delivery model |
"AI-accelerated delivery" with the same headcount and day rates |
Mactores is the agent-native AWS modernization firm. Through our data platform modernization on AWS practice, we ship data modernization to production in weeks, with a fixed date and a fixed fee written into the statement of work before build starts, and when a delay is inside our control, we absorb the overage cost.
That commitment holds because of how the work is staffed. Aedeon, the agent platform we deliver with, handles source discovery, schema mapping, lineage extraction, validation harnesses and parallel-run instrumentation, and it absorbs 60–70% of the engagement work. Our forward-deployed engineers own the target architecture, the data model decisions, cutover and production sign-off. Each of them is an agent-native specialist who has shipped production systems on AWS.
|
Client |
What we shipped |
Result |
|---|---|---|
|
Synaptics |
Smart queues for its chip-design (EDA) clusters on AWS |
Up to 40% more throughput and 75% lower queue wait times |
|
KlearTrust |
A HIPAA-compliant agentic claims platform, in production in 12 weeks |
Replaced a six-month manual review cycle and passed HIPAA and internal audit on first review |
|
Poshmark |
A consolidated AWS-native platform, cut over in stages |
Zero product disruption, on a migration most SI firms had declined |
Mactores is an AWS Premier Tier Services Partner with the Generative AI and Agentic AI Specialization, seven AWS Consulting Competencies including Data & Analytics and Migration, and seventeen AWS Service Validations.
If you're weighing a program like the rental company's, the quickest way to a real answer is a modernization assessment, which comes at no cost to qualified customers. A forward-deployed engineer produces an assessment report, a migration blueprint, a risk register and roadmap, and a working proof, with one module converted by agents, running on the target and tested against your current baseline.