Nobody Is an Expert at Something This New.
We have just done it in more places. Every month we bring what we learned somewhere else to your table.
A standing relationship with senior engineers who are solving your problem in three other companies this quarter. Not a delivery team. Not a statement of work.
Your team and ours, ninety minutes
Yours to keep and change
Before you commit, not after
Quarterly, or when you need it
The part nobody can schedule
Two days a month of senior attention, give or take. Enough to be useful, small enough that nobody has to build a business case for it.
“Can We Just Have Someone to Think This Through With?”
We hear a version of this in most first calls now. Usually from teams further along than they give themselves credit for. They have engineers. They have budget. What they lack is anyone who has already been round this corner.
We are learning too
This did not exist three years ago. Anyone claiming deep expertise is describing something they read. What we have is reps.
More companies, more patterns
We see the same problem in a bank, a carrier and a manufacturer in the same quarter. That is a different vantage point from yours, not a better brain.
The shortcuts and the scars
What worked somewhere else, what quietly did not, and which of your instincts we would back. Told plainly, including when we were wrong.
The AI part is new for everyone, including us. Delivering software that survives contact with a real business is not, and sixteen years of doing that is the only reason the pattern library is worth anything.
No slides prepared in advance. The value is in the conversation, and a deck is usually a way of avoiding one.
The most common question we get about this is the most practical one, and it is fair: what actually happens, and how much of your people’s time does it take?
A Year of This, Drawn Out
Nothing here is a milestone you have to hit. It is roughly the order things tend to happen in, because each one makes the next one easier.
Most teams worth talking to are not at the starting line. They have twenty or thirty agents and automations the business built, nobody is watching them, and that is the urgent problem. Then the last box becomes the first one, and the frameworks get written around what already exists.
The build in the third quarter is where most firms would have started. Starting there is how programs end up with something impressive that nobody owns. And yes, a build is on this diagram: this relationship has a commercial destination and we would rather draw it than pretend otherwise.
Deciding what deserves to be built. Agreeing who owns it once it exists. Giving your people room to try things without anyone getting hurt. Unglamorous, mostly conversation, and the difference between a program and a pile of demos.
Conversation on its own evaporates. So every session leaves behind something written, and these five are the ones teams ask for most often. Each one is yours, in your words, and yours to change.
The Questions Nobody Has a Good Answer To Yet
We do not arrive with these pre-written. They come out of your systems, your team and your constraints, which is the only reason they end up getting used.
“We know it needs governing. We do not know what good looks like.”
An AI governance model
Agent identity, scoped access, audit trails, human gates, kill switches, and who signs off on what. Ours is published openly, so you can read it before you decide we are worth talking to.
“Where should knowledge actually live?”
A knowledge architecture
Most teams have four or five overlapping systems and a growing sense that none of them is the source of truth. This is the architectural answer, not a lecture on why documentation matters.
“How much can the business build on its own?”
A permission boundary
Three lines: what anyone can build unsupervised, what needs a review, and what has to be central. Drawn against the tools your people actually use, usually Power Platform, Copilot Studio or whatever the business found first. Too tight and nothing happens. Too loose and someone shares the wrong thing.
“What happens to QA now?”
An evaluation practice
In an AI-native workflow, testing does not disappear, it changes shape. Your QA people become the ones who decide what a good answer is, which is a bigger job than the one they had.
“We have more ideas than we can possibly do.”
A sequenced use-case list
Ranked by whether the data exists, whether a named person in the business wants it, and whether it can prove itself inside a quarter. Most lists shrink in this exercise, which is the point.
None of these are ours to keep. They are written for your organization, and they stay useful whether or not you ever hire us to build anything. The governance one is already public →
The frameworks matter most when the people who have to live with them helped write them. Which brings us to the part of this that teams tend to underestimate.
The Champions You Already Have Are the Whole Program
Most companies we meet already have people in the business who got curious early and started building things. They are usually the most valuable asset in the effort, and the most likely to be left figuring it out alone.
We would rather teach twenty of your people something useful than deliver one more project. It is better for you, and it makes every conversation we have afterwards a more interesting one.
One more thing worth being upfront about, because it changes what this relationship feels like from the inside. This only works if it runs both ways.
We Are Getting Something Out of This Too
It would be strange to claim otherwise. Every engagement teaches us something we take to the next one, and pretending that is not happening would be the least honest thing on this page.
What you get from us
- Patterns from companies solving the same problem right now
- An honest read on which of your instincts we would back
- Frameworks written for your organization, yours to keep
- Someone senior who will say the idea is not worth doing
- A team that can build it when the moment comes
What we ask of you
- Tell us what actually went wrong, not the tidy version
- Put us in front of the people doing the work, not only leadership
- Push back when our advice does not fit your business
- Let us write up what we learn together, anonymized, for the next team
- Tell us early if this stops being worth your time
The last one is not politeness. A standing relationship that nobody looks forward to is worse than no relationship, and it is easier to fix in month two than in month nine.
Ask Us About the Ones That Are Not on This List
- Landstar: 90% less time searching, across three systems unified into one.
- Bennett: 95% of invoice extraction automated, and a 70% faster cycle.
- Illume: 50% faster due diligence reports, thousands of analyst hours a year.
- Icon Custom Pools: quotes from a full day to five minutes, close rate up more than 40%.
- Renuity: 90% less manual data handling in the commission process.
- SkillCloud: three times the client capacity, 40% faster responses.
Every firm shows you its wins. The more useful conversation is the engagement we scoped wrong the first time, or the build that took two attempts, and we will tell you which was which.
Which leaves the practical question. We price this deliberately low, and it is worth explaining why rather than leaving you to guess.
Small Enough That Nobody Needs to Build a Business Case
AI Advisory
Monthly · three-month minimum · thirty days notice to stop
- Deliberately smaller than a build. This is not where we make our money, and structuring it as though it were would ruin the thing that makes it useful.
- It credits against the first build it produces, the same way our two-week assessment does, so nobody is paying twice for the same thinking.
- Thirty days notice, no conversation required. If the sessions stop being the best ninety minutes of your month, they should end.
- It does not obligate you to build anything with us. Some of the best advice we have given has sent people to a product they could buy instead.
Ask for the figure on the first call, and hold us to answering it in that call rather than in a proposal. It is a flat monthly number. It does not scale with how many of your people show up, because charging by the head is how an advisory relationship quietly turns into a staffing one.
If what you need is hands on keyboards rather than judgment in the room, say so and we will point you at the embedded model. Different offer, different problem, and mixing them up wastes a quarter.
Fair Enough. The Longer Answers.
Is this just consulting with a different name on it?
It is consulting, and we are not going to pretend otherwise. What we would point at as different is the shape rather than the label. There is no analyst team producing a deliverable you did not ask for, no discovery phase you pay for before anything useful happens, and no separation between the people who advise and the people who build. The person in the monthly session is the person who would write the code.
The other difference is that it is cheap and easy to cancel, on purpose. An engagement that costs enough to need defending creates pressure to look busy. We would rather be small enough that you keep it only because it is useful.
We already have an AI team and we are hiring more. What do you add?
Vantage point, mostly. Your team is deep in one company’s version of this problem, which is exactly where they should be. We are shallow in a lot of companies’ versions of it at once, which means we have usually seen your next three problems already happen somewhere else.
The other thing we tend to add is permission. It is often easier for an outside voice to say that a pet project should stop, or that the unglamorous sequencing work matters more than the impressive demo, than it is for someone whose next review depends on the answer.
What we are not is extra capacity. If the constraint is hands, hire, or look at the embedded model.
Our real bottleneck is turning business problems into requirements. Does this help with that?
That is the most common answer we get when we ask where the constraint actually is, and yes, it is most of what these sessions end up being. Everyone assumes the shortage is engineering, and then discovers there is a queue of half-formed ideas that nobody has turned into something a team could build.
Practically, we sit with the person who owns the process, take one workflow apart, and write down what an agent would actually need to do, what it must never do, where a human decides, and what a good outcome looks like. That document is the thing that was missing. It is also the thing that makes the eventual build fast, whoever ends up doing it.
We already have thirty-odd agents running that the business built. Where does that fit?
At the front, not at the end. That is the most common shape we see now and it is a better starting position than a blank page, because you have real usage, real edge cases and real evidence about which teams will adopt something.
What it changes is the order. Instead of starting with a use-case list, the first sessions go to what is already live: what each one touches, which have write access to something that matters, which are quietly wrong and nobody has noticed, and which three deserve to be properly built rather than left as a prototype in someone’s personal environment.
The thing we would push back on hardest is the instinct to respond by centralizing it all. That kills the exact energy that produced thirty agents in the first place, and it usually takes a year to rebuild. The better answer is to draw the permission boundary, put the handful that matter under proper control, and leave the rest alone.
Our CEO is asking about this now. What do the first sixty days look like?
Faster than the monthly rhythm, on purpose. When there is executive attention on this, the useful thing is usually not a strategy, it is a defensible answer to two questions: what is actually running today, and what are we doing about it.
So the first sixty days compress. Two or three sessions in the first fortnight rather than one a month, a written inventory of what exists and what it touches, and one thing chosen that can visibly move before the quarter ends. The frameworks still get written, but they follow the inventory rather than preceding it.
After that it settles into the normal cadence, because sustained monthly attention is worth more than a burst. But nobody should have to wait ninety days for their first useful artifact, and if your CEO is asking, say so on the first call and we will structure it that way.
How is this different from your governance assessment?
The assessment is a fixed, two-week piece of work with a defined output: your agent estate mapped against a set of controls, with the gaps named. It is the right thing to buy when you have agents running and a security team asking questions you cannot yet answer.
This is the standing version, and it is broader. Governance is one of the things it covers, alongside sequencing, enablement, architecture and whatever you are stuck on this month. Plenty of teams do the assessment first and then keep the relationship going afterwards, because the questions do not stop when the report is delivered.
What if we mostly want you to challenge us?
Then say so at the start, because it changes how we run the sessions and it is the most valuable version of this. The default failure mode of an advisor is agreeing pleasantly with whatever the client already decided.
What it looks like in practice: we ask what you are treating as settled, and then we argue with one of those things each month. Sometimes we are wrong and you will have a sharper answer than before. Both outcomes are worth the session.
Who from your side is actually in the room?
A senior engineer who builds these systems, plus a practice lead who has seen how this has gone at other companies. The same two people, month to month, because the value of this compounds only if nobody has to be re-briefed on your business.
We will name them before you commit, and if the fit is wrong we will change them without it being awkward. A standing relationship rests on the specific people in it, and it is better to be honest about that than to pretend the firm is interchangeable.
How does this turn into a build, and are you steering us toward one?
Usually a use case gets sequenced, someone in the business puts their name to it, the data turns out to be good enough, and it becomes obvious. At that point we can build it, and because we already know your systems and your constraints there is no re-onboarding, which is worth real money and real weeks.
On steering: the honest answer is that the incentive exists and you should hold us to it. What we would say is that our recurring revenue comes from operating systems rather than from selling projects, so a client who builds fewer, better things is worth more to us than one who builds a lot of things that get switched off. If you ever feel a recommendation is pointed at our pipeline rather than your problem, say it out loud and we will show you our reasoning.
Can we start smaller than a monthly commitment?
Yes, and quite a few relationships start this way. Bring one question to a single working session, no commitment on either side, and see whether ninety minutes with us is worth the calendar. If it is not, that is a useful thing to find out cheaply.
The one thing we would gently push back on is a series of one-off sessions with months in between. The compounding is the whole point, and a conversation that starts from scratch every time is worth much less than one that picks up where the last one left off.
Everything we advise on is built on Lumynate, our system for building and operating agents: the method, the reusable component library, the guardrails, and the team that keeps it running after go-live. This offer is the part of it that starts before anything gets built.
Bring Us One Question
Thirty minutes, whatever you are currently stuck on, and an honest answer about whether we are the right people to think it through with.
Already know what you want built? Start at how we build instead.