The System Your Agents
Keep Running On.
Most delivery systems make the consultancy faster. This one is about what is still standing a year after we leave.
Five parts: the method, the reusable library, the guardrails, the people, and the operating layer. You will not need all of them on day one, and this page is meant to help you work out which one you actually need.
MethodLibraryGuardTeamsRun
The build is the easy half. This is the part almost nobody sells, and the part that decides whether any of it was worth doing.
“Another Consulting Framework. Great.”
Fair enough, and most of them are a diagram with verbs on it. So rather than ask you to take the word system on faith, here is the test we would apply in your position: can you inspect the parts before you pay for any of them?
The guardrails are free to read
Our governance framework is open. Read the controls before you talk to us. Use them with another vendor if you want.
Every pattern says what it is
The agent rosters mark what we have shipped and what is a pattern. Nothing on the site claims work we have not done.
The first step has a number
Two weeks, from $30K, a verdict. Half of it credits against the build if there is one.
Less time spent searching across three systems at Landstar.
Faster due diligence reports at Illume, thousands of analyst hours a year.
Quote turnaround at Icon Custom Pools, with close rate up more than 40%.
None of that is unique to us. It is simply what 16 years of building production systems leaves behind.
The test runs in the other direction too. We have turned down more engagements than we have taken, and not because we are difficult. The method needs an executive sponsor rather than an enthusiast, one workflow somebody can name out loud, and ninety days where your team can actually make decisions. When one of those is missing we would rather say so on the first call than discover it in month three.
Bring us one workflow. We prove it pays, build it properly, control it so security signs off, and keep it running after everyone else has moved on.
That sentence is the whole system. The five parts below are just what it takes to mean it.
That sentence is a promise, and promises are cheap. These are the five parts that make it keepable, and the shape they make together matters more than any one of them.
What Actually Ships With Every Engagement
These are not five service lines sitting side by side, which is how a diagram like this usually gets read. They are one shape, with each part doing a different job inside it.
Read the loop, not the boxes. Method is the path. Teams is who walks it. Guard is what the Govern stage installs. Run is the arrow that comes back when something changes upstream. Library is the only part that gets richer each time, which is why the second build costs less than the first.
Method
Five stages from first question to running system. Published openly, and you start wherever it hurts.
A verdict, a build plan, a ship date.
Everyone starts at stage one because the deck says so. Most companies do not need stage one.
Library
Everything previous builds left behind: industry rosters, integration patterns, connectors, evaluation harnesses, guardrail configs.
The plumbing. Connectors, evals, guardrail configs.
It never saves time on your data, which is where builds actually run long. Anyone promising otherwise has not seen your data.
Guard
Agent identity, scoped credentials, audit trails, human gates, kill switches. Mapped to the NIST AI Risk Management Framework. Published in full.
Data flows, credential scopes, gates, a tested kill switch.
Almost everyone sells the accelerator. Nobody sells the brakes, and the brakes are what get you into production.
Teams
Our people inside your team, and your people trained to keep it. A Resident engineer, an agent pod, workshops, enablement.
Your engineers have already changed it and watched what broke.
Knowledge transfer booked as a meeting in the final week. Training after the build is a demo.
Run
After go-live: monitoring, evaluation runs, drift, cost, incidents, someone on call. Ninety days included with every build, then in-house or monthly.
Evals still running. Someone named still on call.
Most agents do not break. They drift, quietly, and the first person to notice is a customer.
Nobody ever killed an AI program because the demo took too long.
They killed it because nine months later it was quietly wrong, and the person who would have noticed had moved on.
Which raises the practical question, and it is usually the second one people ask us: where would this even start for us? Almost never at the beginning, it turns out.
One Lifecycle. Start at Whichever Stage Hurts.
No rule says you begin at the first one, and most people do not. Here is where they actually walk in, and what they are usually carrying when they do.
The grey bracket is what a methodology deck assumes. The four arrows are what we actually see. Each one already has a priced door open, so nobody has to buy the stages they do not need in order to reach the one they do.
Assess
Two weeks on one workflow. Is it worth automating, what would it cost, and what breaks. Ends in go, kill or fix.
- AI Readiness Scorecard
- Workflow Opportunity Map
- Prioritized Opportunity List
- Build / No-Build Recommendation
Design
Where the agent acts, where a person decides, and which systems it touches. The integration surface, mapped before anyone codes.
- Technical AI Blueprint
- Integration Surface Map
- 90-Day Sprint Roadmap
- Success Metrics Definition
Build
Fixed scope, fixed ship date. Your engineers in the same repository from week one, not briefed at the end.
- Production System Build
- Integration With Real Data
- Bi-Weekly Demo Cadence
Govern
Identity, scoped credentials, audit trail, human gates, kill switch. The evidence your security team needs to sign.
- Guardrail Design Document
- Live Guardrail Layer
- Evidence Pack for Security
Run
Anyone can demo an agent. Keeping one durable, observable, and on budget is the job.
- AI Operations Playbook
- ROI & Outcomes Report
- Re-Entry for the Next Workflow
Automation is earned, not assumed. Each stage has to produce its own reason to fund the next one, which also means you get a clean place to stop if the answer turns out to be no.
Wherever you start, it starts with people, and not only ours. The part that decides whether any of this survives is whether your own team can carry it once we step back.
The Best Outcome Is You Not Needing Us
Three ways your people get trained, all of them running during the build rather than crammed into a handover week. And below them, the standard our own engineers have to meet before we put one on your project, because you should know what a name on a proposal actually guarantees.
Workflow Discovery Workshop
A working session with the people who actually run the process. We take one workflow apart on a whiteboard and find where an agent belongs, if anywhere.
Half day6 to 12 peopleOpens an assessment
Executive Session
Where agents fit, what to fund this year, what to say no to, and what your competitors are actually doing rather than announcing.
Half dayExec team plus ITYou leave with a shortlist
Team Enablement
Your developers work in the same repository as ours from week one. Same guardrail configs, same evaluation suite. By go-live they have already broken something and fixed it.
Runs with the buildHands onYou own the extensions
Internal standard
Lumynate Certification
Our internal standard for what an engineer has to have done before we place them inside a client team. Built agents under this governance model, and operated them after launch.
Internal, first cohort this yearTechnical Council owns it
The engineer who runs your workshop is the one who builds it. Not a facilitator, and not a practice lead who hands off once the room empties. The person at the whiteboard writes the assessment, and they are still there in month six when something upstream changes.
If that sounds like a small thing, it is the difference between a workshop that produces a document and one that produces a system.
And Afterwards, Someone Who Keeps Showing Up
The diagnostic ends, the build ships, and then the questions keep coming. What do we do about the thirty things the business already built. Where should knowledge actually live. How much can we let people build on their own. Nobody has good answers to those yet, including us, and they do not arrive on a schedule that suits a statement of work.
So for teams already working with us, there is a standing version: a monthly session with the same senior engineer and practice lead, one framework written down each month, and a design review whenever you want a second opinion before you commit. It is deliberately small. It is not a delivery team, and if the sessions stop being useful they should stop.
Ask about it on any call. It is the part of Teams that starts once we already know your systems, which is the only reason it is worth anything.
Which leads somewhere most people are too polite to raise on a first call, and really should. If your team is meant to carry this, they have to own it. So here is exactly what that means.
When We Leave, What Is Actually Yours?
Here is where the line sits, drawn before you ask a lawyer to find it.
code, prompts, configuration
your workflow, your edge cases
yours to run and to change
in your systems, your retention policy
written for whoever operates it next
Crosses to you under license, for as long as you run the system.
Generic integration patternsConnectors to common systemsEvaluation harness scaffoldingGuardrail configurations
Came from other builds.
Goes on to serve the next one.
Crosses back to us: generic learnings only. Never your data, never your workflow.
Every firm with a named system has an IP flywheel, and most of them only draw the arrow pointing back at the firm. Both arrows are on this page because a procurement lawyer is going to find the second one anyway, and it is better read here than discovered in a redline.
It keeps running if you replace us, and that goes in the agreement, not just on a web page.
One more fair question, and you have probably had this pitch three times this year already. Every firm has a named system now. It is worth a minute on what they each actually promise.
Everybody Has One of These Now. Read What It Promises.
Ten launched in the last two years, from the Big Four down to firms our size. Everything on the left is taken from their own pages.
This is the whole argument, and it is checkable. Go and read their pages. Three of the ten list a run-side capability. None of them shows one. We are not claiming the left side does not matter, only that it has never been the reason an agent program died.
Where they win. On raw throughput, the large firms have more people and more platform partnerships than we do. If your project is a big migration and volume is the whole problem, weigh that seriously. Our case is narrower, and it is the one drawn above.
These Are Launch Numbers. Ask Us About Month Nine.
Named clients, published figures. And every one is a go-live number, which is the same proof we just said the industry leans on too hard.
Less time searching. Three systems unified into one.
Of invoice extraction automated, and a 70% faster cycle.
Faster diligence reports. Thousands of analyst hours a year.
Less manual data handling in the commission process.
Quote turnaround, with close rate up more than 40%.
So please ask us a harder question on the call. Ask which one broke after go-live, what changed upstream, who caught it and how long it took. We will name the client, and that conversation will tell you far more than the numbers above.
The senior engineers who ship it are the ones you meet on the call.
All of that is the same whoever you are. One part is not. How fast any of it moves depends on whether we have built in your industry before, because that decides how much of the Library is already full on day one.
Five Industries Where the Library Is Already Full
A blueprint is not a product and it is not a discount. It is the accumulated Library for one industry: the use cases mapped, the data models built, the integration patterns and guardrail configurations already written and already run in production. In these five, your build does not start at zero.
Financial Services Blueprint
Middle-office work that has to clear security review and the model risk queue before it ships. The agent reads and assembles; a named person still decides.
- Client onboarding and KYC document extraction
- Credit memo drafting, with the recommendation left to the analyst
- Reporting assembly with every figure cited to source
- Screening and alert triage with the evidence attached
Private Equity Blueprint
Diligence agents for the deal team and operating agents inside the companies. Build the pattern once in one portfolio company, then deploy it into the next as configuration rather than a rebuild.
- Financial due diligence and data room extraction
- Operating copilots inside portfolio companies
- Portfolio KPI monitoring, read-only across companies
- Investor and LP reporting assembly
Logistics Blueprint
The check calls, the missing POD and the load that went sideways at four in the afternoon. Document, visibility and settlement work where the rules are known and the volume is punishing.
- Document processing for bills of lading, PODs and invoices
- Shipment visibility across TMS, tracking feed and driver updates
- Order exception handling and resolution routing
- Knowledge and SOP search across tariffs and procedures
Insurance Blueprint
Queue-heavy work where a good answer is not enough, because an auditor, a reinsurer or a regulator will ask how it was reached two years later.
- Claim documents read, with every field traced to its page
- Underwriting submissions assembled for the underwriter to decide
- Intake and triage, measured before any of it is automated
- Third-party inspection reports turned into structured events
Real Estate & Hospitality Blueprint
Guests and residents do not ask questions during office hours. Lease and policy answers, owner reporting and the revenue work in between, read from your own documents at an hour when nobody is at the desk.
- Lease abstraction, read-only, never speaking to a resident
- Guest and tenant communication that answers, then escalates
- Owner and investor reporting across systems that will never merge
- Guest feedback categorized and recurring themes surfaced
We have also shipped in healthcare, retail, professional services, HR technology and energy, so read the absence of your industry as less library rather than less experience. The method does not change. The blueprint only decides how much of it is already built the day you start.
So, practically. You do not have to decide about any of this today, and you certainly do not have to buy a system. You only have to pick which door matches what is broken right now.
Four Doors. Nobody Buys the Whole System First.
Pick the one that matches what is broken today, and ignore the rest for now. Each stands on its own, and each composes with the others later if it turns out you want more.
AI Pilot Rescue
2 weeks · delivered as the Lumynate ROI Audit
A go, kill or fix verdict per initiative. Half the fee credits against your build.
Governance Assessment
2 weeks
Your agent estate mapped against NIST-aligned controls. Framework published open.
Embedded AI Teams
Resident engineer
A senior AI engineer inside your team, backed by the full RTS bench.
Production Agent Build
90 days of operation included
One workflow shipped as a governed system, with your engineers building alongside ours. First builds typically land in the low-to-mid six figures.
If the answer is that you should not build anything yet, the assessment says so, and you still leave with the workflow mapped, the integration surface costed, and a document your CFO can file against last year’s question. Our clients run from a few hundred people to the Fortune 500. What they share is one stuck workflow and nobody spare to fix it.
Most people carry on talking to us monthly afterwards. That is a conversation for once you have picked a door, not before.
Fair Enough. The Longer Answers.
What is Lumynate, in one paragraph?
Lumynate is the system every agentic engagement at RTS Labs runs on. It has five parts. Method is the lifecycle we work through: assess, design, build, govern, run. Library is the accumulated work from previous builds, meaning the industry agent rosters, the integration patterns, the evaluation harnesses and the guardrail configurations, so your build does not start at zero. Guard is the governance stack that decides whether an agent is allowed to reach production: identity, scoped credentials, audit trails, human gates, kill switches. Teams is the people side, both our engineers working inside your team and the training that leaves your people able to run what we built. Run is what happens after go-live: monitoring, evaluations, drift, cost, incidents.
It is not a product you license and it is not a platform you log into. It is how the work is done, which parts of it are reusable, and what stays behind when we go.
What happens the day a supplier changes their file format?
This is the question, and it is how most agent programs actually die. So here is the mechanism rather than a reassurance.
The evaluation suite runs on a schedule against a held-out set of real cases, not only when someone deploys. A format change shows up as evaluations failing, usually before a human notices anything, because the agent starts producing lower-confidence output on inputs it used to handle cleanly. That fires an alert to a named engineer, not a shared inbox. Inside the ninety days, and on any monthly arrangement afterwards, fixing it is our job and it is not a change order. The agent also fails closed rather than guessing, so the worst case is work queued for a person, not wrong data written into your systems.
The other half of the answer is that your engineers were in the repository during the build for exactly this reason. A format mapping is the kind of change an internal team should be able to make in an afternoon, and if they cannot, the handover did not work and we would rather find that out in month two than month twelve.
What happens after go-live?
Ninety days of operation are included with every build, and that is not a warranty period. It is monitoring, evaluation runs against a held-out set, drift checks, cost tracking and someone on call when the agent starts behaving differently because something upstream changed.
Most of what goes wrong with a production agent is not a bug in the agent. It is an input that changed shape, a model version that shifted behavior, or a volume of edge cases nobody saw in testing.
After the ninety days you either take operation in-house, which is what the enablement was for, or move onto a monthly AgentOps arrangement with defined response times. Both are normal outcomes and we do not price the handover as a penalty.
What do we own at the end, and what stays yours?
The agent we build for you is yours. The code, the configuration, the prompts, the evaluation suite written for your workflow, the runbook and the audit history all belong to your business and live in your environment. It keeps running if you replace us, and we will put that in the agreement.
What we license rather than assign is the reusable half of the Library: the generic patterns, connectors and guardrail configurations that came from other engagements and will go on to serve future ones. You get a license to keep using them for as long as you run the system. You do not get ownership of components that were not built for you, and neither does anyone else.
If you want that line drawn explicitly before you sign, ask on the first call and we will walk through exactly which artifacts fall on which side.
Our security team blocked the last agent from touching the ERP. What do you actually hand them?
A written pack, before the build rather than after it. It contains the data flow diagram showing every system the agent reads from and writes to, the credential scope map naming exactly which permissions it holds in each one, the audit trail specification, the human-gate matrix listing which actions require a person and who that person is, evidence that the kill switch has been tested, and the list of models and vendors involved with where the data goes.
The default posture is read-only into systems of record. An agent earns write access to one system at a time, on a specific action, with a named approver. If your security team’s answer is still no on the ERP, that is a legitimate answer and the design changes rather than the argument continuing: the agent drafts and a person commits.
The controls behind that pack are published in full on our governance page, so your security lead can read them before you spend anything, and use them to interrogate any other vendor you are talking to.
Every consulting firm has a named AI system now. How is this different?
Read what the others actually promise. Almost every named delivery system in this category is a claim about the consultancy: our agents write the first draft, our discovery takes days instead of weeks, our teams ship faster. Those are real improvements and we use the same techniques internally, but every headline number in the category is a build-time number. Nobody publishes what happened after go-live.
Lumynate is pointed at the other end. The parts that matter most, Guard and Run, only exist because an agent has to keep behaving when the model changes underneath it, the upstream file format changes, and the person who championed it has moved on.
That is also why we publish the governance framework rather than treating it as the secret. If our advantage were the checklist, publishing it would be foolish. The advantage is having run the thing at three in the morning when it broke.
Do we have to take all five components?
No, and almost nobody does at first. The most common entry is one stage of Method: a two-week assessment on one workflow, ending in a go, kill or fix verdict. Guard gets bought on its own by companies that already have agents running and a security team asking questions about them. Teams gets bought on its own when the constraint is hiring rather than knowing what to build. Run gets bought on its own by companies whose agent someone else built and nobody now operates.
The components are designed to be sold separately and to compose when you want more than one. What we would push back on is buying a build with no Guard and no Run attached, because that is the shape of engagement that produces a working demo and a dead system nine months later.
Are you training our team, or replacing it?
Training it, and the commercial incentive here is worth being blunt about. A firm that bills by the hour has every reason to keep knowledge on its own side of the table. Our answer is that the recurring part of our business is operating systems and licensing patterns, not selling hours against a knowledge gap, so an internal team that can extend what we built makes us more useful rather than less.
In practice the enablement runs alongside the build rather than as a handover event at the end. Your engineers work in the same repository, review the same guardrail configurations, and run the same evaluation suite. By go-live they have already changed things and watched what broke, which is the only version of knowledge transfer that survives contact with production.
What do the workshops and training cost?
The workflow discovery workshop and the executive session are scoped and priced with the engagement they belong to, and the discovery workshop is normally the opening of an assessment rather than a separate purchase. Team enablement is priced by cohort size and length, because a two-day session for four engineers and a six-week program for a platform team are not the same thing.
If you want a number before a call, tell us how many people and how deep, and we will give you a fixed one rather than a range. We would rather quote a real figure for your case than publish an average that is wrong for everybody.
What is Lumynate Certification?
It is our internal standard for what an engineer has to be able to do before they can be placed as a Resident inside a client team. Our Technical Council owns the curriculum, and the first cohort runs this year.
We are describing it here because it is the honest answer to a question clients ask often, which is what a named engineer on a proposal actually guarantees. It means someone has built agents under this governance model, operated them after go-live, and been assessed on both.
It is not a public course you can enroll in today, and we are not going to pretend otherwise. The client-facing version follows once the internal one has produced people rather than a syllabus.
Is this just a rebranded methodology deck?
It would be, and that is a reasonable thing to suspect, because most of them are. The difference is whether the parts exist separately from the diagram, so the test we would apply in your position is to ask what you can actually go and inspect.
The governance framework is published in full and free to use, so you can read the controls before you talk to us and use them with another vendor if you prefer. The agent rosters for financial services, private equity, logistics, insurance, real estate and hospitality are on the site with each pattern labeled by whether we have shipped it. The prices for the first two rungs are published. The people who would run your engagement are named on the pages.
A methodology deck cannot survive that much specificity, which is roughly the point of publishing it.
We already have an internal AI team. Where does this fit?
Usually at the two ends rather than the middle. Internal teams are generally good at building the thing and short on two other things: the controls that get a security review passed, and the operating layer that keeps an agent honest for a year.
So the common shape is that your team builds, Guard supplies the governance model and the review evidence, and Run covers operation until your team is ready to take it. The other common shape is capacity, where a Resident engineer joins your team for a period and works as one of yours.
What we would not suggest is parallel build tracks. Two teams building agents against the same systems with different guardrail conventions is worse than either team working alone.
Our data is messy. Where does that leave us?
Roughly where everybody starts. The assessment includes an honest read on data readiness, and the finding goes both ways. Often there is more usable data than the team believes, sitting in a system nobody thought to look in. Sometimes there is a specific gap that has to close before a build makes any sense at all.
When it is the second one we say so, and the recommendation is a data workstream first rather than a build that will run long and quietly underdeliver. That verdict is the entire point of spending two weeks before spending six months. It is cheaper to find out in week two.
What does this actually cost?
The assessment is two weeks, from $30,000, and half of it credits against the build if there is one. Design typically runs $15,000 to $25,000. A build ranges from $75,000 to $250,000 and up, and the range is that wide because it is driven by how many systems the agent has to touch and how much of your data has to be untangled first, not by how clever the agent is.
Governance and the first ninety days of operation are included with a build rather than sold back to you afterwards. Most people start with the assessment so that both sides are looking at the same evidence before anyone commits to the larger number.
Do we need our own AI or engineering team?
No, and the design assumes you may not have one. The assessment includes a read on what your team can carry today, and the training exists precisely so that operating the thing does not require us indefinitely. Plenty of clients arrive with no internal AI capability and leave with trained staff and an operations playbook they run themselves.
If you do have an internal team, they are in the repository from week one rather than briefed at the end. That is not a courtesy. It is the difference between a handover that works and one that produces a system nobody inside the building can change.
How long until we see a return?
Most clients see measurable movement during the build, at roughly eight to twelve weeks from the start, and that is a function of scoping to one workflow rather than a platform. Full return against the investment usually lands somewhere between six and eighteen months depending on scope.
We would rather be held to the first number than the second. The first one is ours to control. The second one depends on how much of the workflow you route through the agent once it has proven it works, and that decision is yours.
We already have AI tools in place. Where does this fit?
This is one of the most common rooms we walk into: three to five AI subscriptions, no integration layer, and nobody able to point at a number that moved. The assessment maps what you already own against actual workflow impact, which means the honest recommendation is sometimes to cut rather than to build.
Design then connects whatever survives that into something coherent. Existing tools are genuinely an asset here, and not only because they are paid for. They are the fastest evidence you have of which workflows your people actually wanted automated.
Bring Us One Workflow
Thirty minutes, one workflow, and a straight answer about whether an agent belongs anywhere near it. If the answer is no, we will tell you on the call and it will not cost you anything.
Looking for agents in your industry instead? Start at our agentic AI practice.