What we do

Three ways in. All of them start with your context.

TanX Labs is an AI transformation studio. Most engagements begin with a review, because the fastest way to waste a year on AI is to build before you know what your business actually knows. But you can start anywhere — with a review, a plan, or straight into a build, if you already know what you need.

Book a fit call Why context first

Start here if

AI Review2–3 wks

You do not yet know where AI would actually pay, or what your data and systems can support.

AI Transformation Strategy4–6 wks

You know roughly what you want and need it sequenced, costed and baselined before you commit.

AI ImplementationFrom 6 wks

You have a plan you believe in and want it built, context layer first.

Not sure? The review is the cheap way to find out.

Compare the three

Ten seconds to know where you start.

AI Review

Start here if…: You don't yet know where AI would actually pay off, or you suspect shadow AI is already a problem and want to see how big.
Duration: 2–3 weeks, fixed scope
What it costs you internally: Roughly 6 hours of your team's time over three weeks — about two hours a week, mostly from the people who do the work.
You leave with: A scored context-readiness rubric, a systems and data map, a shadow-AI exposure assessment, and a ranked workflow shortlist.

AI Transformation Strategy

Start here if…: You already know AI matters and need the sequenced plan — what to build first, what it costs, and how you'll know it worked.
Duration: 4–6 weeks
What it costs you internally: Roughly 10 hours of your team's time across six weeks — under two hours a week, mostly your leadership team and whoever owns the systems.
You leave with: A staged 12-month roadmap, a target architecture, a governance and permissions model, a build-vs-buy call per capability, and a baselined measurement plan.

AI Implementation

Start here if…: You have a plan — yours or ours — and you're ready to put working software in front of your team.
Duration: Staged, from 6 weeks per increment. Planning ranges: a first automation in 2–4 weeks, as a bounded early step; a governed assistant and automations in 4–8 weeks; a connected context layer in 3–5 months.
What it costs you internally: Scoped phase by phase. We name the internal time a phase needs before it starts, not after.
You leave with: Connectors, the context layer, a governed assistant, persona agents where they're warranted, and the runbook your team uses to operate it.

	01 AI Review	02 AI Transformation Strategy	03 AI Implementation
Start here if…	You don't yet know where AI would actually pay off, or you suspect shadow AI is already a problem and want to see how big.	You already know AI matters and need the sequenced plan — what to build first, what it costs, and how you'll know it worked.	You have a plan — yours or ours — and you're ready to put working software in front of your team.
Duration	2–3 weeks, fixed scope	4–6 weeks	Staged, from 6 weeks per increment. Planning ranges: a first automation in 2–4 weeks, as a bounded early step; a governed assistant and automations in 4–8 weeks; a connected context layer in 3–5 months.
What it costs you internally	Roughly 6 hours of your team's time over three weeks — about two hours a week, mostly from the people who do the work.	Roughly 10 hours of your team's time across six weeks — under two hours a week, mostly your leadership team and whoever owns the systems.	Scoped phase by phase. We name the internal time a phase needs before it starts, not after.
You leave with	A scored context-readiness rubric, a systems and data map, a shadow-AI exposure assessment, and a ranked workflow shortlist.	A staged 12-month roadmap, a target architecture, a governance and permissions model, a build-vs-buy call per capability, and a baselined measurement plan.	Connectors, the context layer, a governed assistant, persona agents where they're warranted, and the runbook your team uses to operate it.

1AI Review

AI Review.2–3 weeks, fixed scope.

Most businesses cannot yet tell you which three processes are costing the most in rework, delay or missed margin, let alone which of those would respond to AI. We spend two to three weeks finding out, before anyone commits to building anything.

It is for a leadership team that suspects AI matters, is not sure where, and does not want the first serious step to be a large build.

W1
Systems and data map, stakeholder interviews
We walk the systems you actually run — ERP, CRM, accounting, the shared drives, the inboxes people privately admit hold the real process — and sit down with the people who do the work, not just the people who manage it.
W2
Context-readiness scoring, shadow-AI exposure assessment
We score what we found against a fixed rubric, published at /context, and separately map what has already been pasted into consumer AI tools and what that has exposed.
W3
Workflow shortlist, ranked, readout
A shortlist of candidate workflows ranked by payback and feasibility, delivered in a session with your leadership team, not left in a slide deck nobody opens again.

You leave with

01
Context-readiness rubric score
Where your systems, data and people stand against a fixed rubric — published, not proprietary.
02
Systems and data map
What you actually run, not what the org chart says you run.
03
Shadow-AI exposure assessment
What has already gone into consumer AI tools, and what that has exposed.
04
Ranked workflow shortlist
Candidate workflows ordered by payback and feasibility, not by novelty.

What this is not: it is not a build, and it is not a vendor bake-off dressed up as a review. We are scoring your context and your exposure, not shopping your requirements around to see who bids lowest.

See the rubric we score against

2AI Transformation Strategy

The sequenced plan. 4–6 weeks.

A review tells you where AI would pay. A strategy tells you what to build first, in what order, and what it will cost before you commit a dollar to building it. Four to six weeks, done with the people who will own the roadmap afterwards.

We size the model to the job.

A classification task does not need a frontier model, and a frontier model does not get cheaper by using it everywhere it does not need to run. Run cost should trend down over a programme, not up.

The cost model in a strategy document also has to include the parts most vendors leave out: connector maintenance, model spend at the volumes you will actually run, and the internal time someone on your team will spend operating what gets built. Leave any of those out and the roadmap looks cheaper than it is.

01
Target architecture
Where the context layer sits, what feeds it, and what it exposes to an assistant or an agent.
02
Staged roadmap, 12 months
Sequenced so each stage pays for the next, not one plan sized for the whole year and negotiated down later.
03
Governance and permission model
Who can ask what, of which system, and what happens the day a permission changes.
04
Build-vs-buy per capability
Some of what you need already exists and is cheaper to buy. We say which, capability by capability.
05
Baselined measurement plan
Hours by function, quote turnaround, rework rate, cash days and on-time delivery, recorded before anything ships.

3AI Implementation

We build it. Staged, from 6 weeks per increment.

Context layer first, then a governed assistant, then persona agents on top of it. Fixed-scope increments, so each phase funds the next rather than asking you to approve a year of work up front. The first increment is sized so a working automation can go live inside its first 2–4 weeks, while the deeper connection work carries on.

Fig. 1What the build actually assembles

01 · Systems you own

ERP
CRM
Accounting
Email & calendar
Documents
Telephony

02 · Context layer

Identity
resolves who is asking, first
Permissions
reads as that person, never around them
Entity resolution
one customer, one job, one asset
Precedent & policy
your standards, quotes, decisions
Freshness control
live where it must be current

03 · What uses it

Governed assistant
Persona agents
Alerts
Reporting

every answer cites its source

What ships

A connected context layer is a three to five month build. We will not pretend otherwise, and we will not start it before a review or a strategy has told us it is the right money to spend next.

01
Connectors
Into the systems you already run — read access first, write access only where a workflow needs it.
02
Identity and permission resolution
Every read happens as the person asking, not around them.
03
Entity resolution
One customer, one job, one asset, held as one record instead of four half-matching ones.
04
The assistant
A governed assistant your team can ask questions of, with the source cited on every answer.
05
Persona agents
Where the workflow warrants it — an estimator, an admin, a quoter, carrying a specific standing job.
06
The runbook
How your team operates, extends and eventually replaces what we built, without us in the room.

4How we surface it

Most of your context has never been written down. Here is how we get it out.

Ask a leadership team what their business knows and you get the official answer: the manual, the CRM fields, the reporting pack. Ask the same question a different way — when did a job last go over budget, and who signed off on the exception — and a different, more accurate business shows up. Surfacing context is not an interview exercise. It is a method, and it runs the same way on every engagement, whether the job is a two-week review or a staged build.

4.1
Mine the systems first, not the people
Closed-out jobs, won and lost quotes, invoices, service history, the email thread where someone explained why an exception got approved. This is the cheapest context in the business, because it is already recorded, so we pull it before we book a single hour with anyone. Every hour we don't spend re-deriving what a system already proved is an hour we can spend on what genuinely never got written down.
4.2
Reconcile entities before anything else
The same customer, job, site or asset usually exists under four different IDs in four different systems, and until that's one entity, every later answer is subtly wrong — a precedent gets missed, a variance gets pinned on the wrong job. This is the unglamorous majority of the work: more engineering than anything built on top of it, and invisible when it's done properly. More on why this is most of the job.
4.3
Interrogate the exceptions, never the happy path
Ask "how do you quote a job?" and you get the process diagram everyone in the room already agrees on — accurate, and mostly beside the point, because it's the version that was already written down. Ask "when did you last override the standard rate, and why?" and you get the actual rule, the one that lives in someone's judgement and gets applied whenever a real job doesn't match the diagram. Every override, discount, refusal and escalation is a policy nobody wrote down. We go looking for those specifically.
4.4
Shadow the decisions, do not run a workshop
A workshop produces the tidy version of how work gets done, because that's what a room full of people agrees to say out loud together. We would rather sit with the estimator while they price three real jobs this week and watch what they check, what they skip, and where they pause. The pause is the signal — hesitation marks a judgement call, and judgement calls are the context worth capturing. Nobody hesitates over something that's actually written down.
4.5
Capture it as something executable, not a document
A written procedure gets filed, read once, and slowly stops matching what actually happens, which is the failure mode that put us in the workshop in the first place. The same rule, encoded against the context layer instead, gets applied on every job it's relevant to and can be checked against history rather than trusted on faith. This is the part that changes the incentive: telling us the rule once now saves the person who knows it from being asked again, instead of costing them an afternoon writing something nobody reads.
4.6
Test against history before trusting it
Before an encoded rule goes near a live job, we replay it over jobs you've already priced or decided and compare the result against what a person actually did. A disagreement is one of two things: a bug in the rule, or an undocumented exception nobody mentioned in the room. Both are worth finding before the rule runs unsupervised, and neither shows up if the only tests you run are hypothetical.
4.7
Keep it alive
Context decays the moment maintaining it stops. New precedent has to flow in as jobs close, not get reconciled in a once-a-year review, and every override a person makes on top of an assistant's answer should feed back in as signal, not get logged and forgotten. A context layer left unmaintained goes stale the same way an abandoned policy document does — just less visibly, because it keeps answering. It just answers with last year's rules.

Ask how the job is done and you get the process. Ask when it last went wrong and you get the rule.

The honest part

This is the slowest part of any engagement, and the part most likely to stall. It depends on the time of the people who are hardest to free up — the senior estimator, the ops lead, the person who has quietly been making the calls for a decade — and there is no way to compress that by adding more people or more tooling to the exercise. The knowledge only exists where it exists.

What we do about it: short sessions, scheduled a week or more out, run against real jobs already on the board rather than hypothetical ones. Twenty minutes watching an actual quote get priced beats an hour discussing quoting in the abstract, and it is a smaller ask of someone's calendar. A business unwilling to give up that time will not get a useful context layer, full stop. We would rather say that before an engagement starts than promise a timeline we cannot keep on the part of the work that depends on someone else's diary.

Why this knowledge never gets written down on its own

5How we work

The same engagement model, every time.

Scoped and built by the same people

The people who scope the work are the people who build it and hand it over. No bench swap partway through.

Fixed-scope phases

Each phase has a defined start, end and deliverable. We do not bill by the open-ended hour.

Your systems, your accounts

Everything runs in infrastructure and accounts you control, under credentials you own, not ours.

No lock-in, you own what we build

The code, the connectors and the context layer are yours. If you never call us again, it keeps running.

A runbook, not a dependency

We hand over how to operate, extend and eventually replace what we built. That is the point of a runbook.

Not sure which one? Start with a fit call.

Tell us what you are trying to fix and we will tell you honestly which engagement is next — including if the answer is none of them yet.

Book a fit call