Skip to content
bearingbridgeai

Training

Fluency, measured.

The teams that get real value from AI are the ones who use it fluently. That fluency is learnable, and it comes from practice on real work, not from watching videos.

Talk to us about AI→See the curriculums ↓
Room
eight, no more
Result
measured twice
Cyril Drouin leading a hands-on AI training session, gesturing at a shared screen while participants work on their own laptops
// hands-on · capped at eightYour real work on the screen. Measured before and after.

The gap

Most of that gap is fluency.

That means reaching for the right tool without thinking about it, writing a prompt that lands the first time, and shipping work faster because a person and a model are doing it together instead of taking turns.

People have the tools and use a sliver of what they can do, so the training worth paying for is the kind that moves a team from occasional prompts to real work done faster. We measure the before and the after, so what you get is evidence the gap is closing, not a hope that it is.

Two-thirds of organizations report productivity gains from AI. Only one in five turns those gains into revenue.

Deloitte, State of AI in the Enterprise, 2026

report productivity gains0%

turn those gains into revenue0%

The method

We train the way we run pilots.

We measure where your teams stand, agree what “trained” means, and run the practice on the work they actually do. Then we measure again, so the gain shows up in dated numbers you can point to.

Measure

where your teams stand

Practice

on the work they actually do

Measure again

dated numbers you can point to

The curriculums

Three tracks, built around who is in the room.

Every track runs on your own work, in the tools your teams already use. Groups are capped at eight, so everyone works on their own material with nowhere to coast.

Each track opens with a short, dated skills read, so the sessions target real gaps instead of a generic syllabus. The modules below are a starting point; in practice we tailor them to your teams nearly every time.

We teach this because we do it. Our own product runs on the same stack the builder track uses, and the sessions are led by the people who ship on it, not a training department.

Bring a real AI proposal on your desk, a vendor you are weighing, and your actual roadmap. The day is a working session: by the end each person has pulled apart a live case, pressure-tested a vendor pitch, and scored their own shortlist, on paper, to take back to their board.

  1. Tear apart a real business case.

    Each participant brings a proposal they are actually being asked to fund, and works it against the checklist: cost per run, the dated baseline, the success metric, the kill criterion. They mark what is missing and leave with a marked-up case and the questions they now have to ask before signing.

  2. Run the five questions on a real pitch.

    Working from a vendor pitch they are weighing (or one we supply), each person puts it through the five that expose a demo dressed as a pilot: what was the baseline, who graded the output, what did each run cost, what would have made you stop, what happens at full volume.

    Output: a go or no-go call they can defend.

  3. Sort your own use cases.

    Each person lists the AI ideas live in their organization and sorts them into build, buy, or solve-it-cheaper-without-AI. They practice writing the “no” that a rule, a spreadsheet, or a hire makes the honest answer, and walk away with a shortlist and a kill list, both with reasons.

  4. Write your guardrails.

    Each participant drafts the guardrails their own workforce needs before scaling: who can run what, budget caps per person and per company, the safe-use rules, the monthly rhythm.

    Output: a one-page governance sketch for their unit.

  5. Score it, out loud.

    Each person scores their top use case on feasibility, data-readiness, and impact in the same frame the strategy roadmap uses, and defends the score to the room. They leave with a first ranking they built, not one we handed them.

By the end of the day, each person has done real work on their own material: a case marked up, a vendor call they can defend, a shortlist and a kill list, a governance sketch, and a use case they scored and argued themselves.

Bring your real work, the tasks that actually eat your week, on your own accounts. Nobody watches slides. By the end each person has built and measured a workflow they use the next morning.

Day one, build your toolkit.

A full working session, on the function’s real tasks throughout.

  1. Map your own week.

    You write out your real week and mark the tasks AI can move and the ones it cannot, ending up with a personal hit-list in priority order.

  2. Write prompts that land.

    Working on a real task from that list, you draft, test, and fix prompts until the output is usable, carrying context, examples, and a clear output shape. You leave with a saved prompt that does a real job.

  3. Build a workflow you will reuse.

    You chain the steps of a recurring task into a repeatable workflow, a weekly report, a first-draft pipeline, a review pass, and run it once end to end. What you keep is a named, saved workflow, not a screenshot.

  4. Build one agent, find its edge.

    You stand up a no-code agent on a real low-risk task and push it until it breaks, so you see the lift and the limit first-hand.

    Output: a working agent and a clear sense of where not to trust it.

Day two, prove it moved.

A second full working session.

  1. Set your own baseline.

    You pick a real task, time it and grade its quality as it is done today, then rebuild it as an AI-assisted workflow in the room.

    Output: a dated “before” number and a working “after.”

  2. Run it live, measure again.

    You run the new workflow on real work and take the same measurement. You walk away with a personal before-and-after you own, and the method to keep taking it after we leave.

Leaves the room with named workflows in their own accounts, a personal before-and-after on a real task, and the habit of measuring it.

Bring one real use case from your backlog. Over two days the team builds it in front of the keyboard, from model choice to a documented, tested system, and walks out with the working thing, not notes about it.

  1. Benchmark and route the models.

    The team runs their own task set against Western and Chinese models, in their working languages, under their actual cost and residency constraints, and picks a routing scheme from the results. They walk away with a benchmark table and a routing decision they can defend.

  2. Wire the orchestration.

    They coordinate the chosen models and tools past the single-model prototype, placing the decision points and marking which ones need governance.

    Output: a working multi-step pipeline on the real use case.

  3. Build the evaluation harness.

    The team builds the harness that grades output honestly: task sets from real work, blind grading where quality is subjective, the metrics that matter (quality, cost per thousand runs, latency, governance fit), then reads its own scores without flattering the model.

    Output: a running eval harness and a first scored result.

  4. Cost and residency it, for real.

    They put their build against live cost, latency, and data-residency limits and cut what fails, because a model that breaks a residency or confidentiality rule is out regardless of its scores. What comes out is a cost ledger and a pass or fail on each constraint.

  5. Write the handover.

    The team documents the routing logic, the eval harness, the cost ledger, and the decision points so the build outlives whoever wrote it.

    Output: a handover doc that lets the next engineer run and defend the system.

Leaves the room with a real backlog use case carried through model selection, orchestration, and evaluation, plus the harness and documentation to run and defend it after we leave.

Pricing

What it costs.

Two ways to pay. Per head suits a small group of three or four from one team. The per-session rate is for a full room of up to eight, and works out lower once you are filling the seats.

“From” is the floor, for a standard session at your site: travel, heavy tailoring, or extra languages in the room move it. And if you want to try us first, the skills read runs on its own and comes off the price of a full session booked afterward.

Sessions run on-site by default, or remote if your team is spread out. A week or two of lead time is usually enough.

// do the math on your group

people in the room

4

per head

$5,200

from $1,300 × 4 people

per session

$5,000

one room, up to eight, one full day

Reference figures, “from” floors. We quote both, you take the cheaper, and the number is confirmed in writing before anything is booked.

// what a full program looks like, start to finish

Skills readshort, dated, runs on its own
The sessionone or two full days
Applied stretchreal tasks between the days
Read againa month later, same tasks

The skills read runs on its own, and it comes off the price of a session booked afterward. Everything to the right of it is optional until you have seen the first number.

FAQ

Questions we get.

What happens after the training?

You keep what was built: the workflows, the prompts, the eval harness, the scored shortlist, all in your own accounts. The measured before-and-after tells you whether it worked, and we are available for a follow-up session or a check-in if a team wants one. We are not trying to become a standing line in your budget.

Do you train on specific tools, or on AI in general?

On your tools, in the accounts your teams already use, across the models that fit your tasks and your compliance rules. Tool-agnostic where it helps, specific where it matters.

Can training come attached to a pilot?

Often, and it is the strongest version. The practitioner and builder tracks slot onto the end of a pilot, so people are trained on the exact system they are about to run.

Can we start small?

Yes. The skills read that opens each track can run on its own first: a short, dated look at where a team stands, so you see how we work before booking a full session. Most clients start there or with the Leadership day.

Why cap the room at eight?

Because everyone builds something, and building gets watched. Past eight, the session quietly turns into a demo with an audience: two or three people work and the rest take notes they never open again. Eight is the number at which we can still sit with each person on their own task, read what they produced, and correct it before the habit sets.

What if the room is at very different levels?

That is the normal case, and the skills read is what makes it workable. It tells us who is already running these tools daily and who opened one twice, so we pair rather than average: the further-ahead people get a harder version of the same task instead of waiting, and nobody is walked through a screen they mastered last year. What we avoid is a room where half the seats are bored.

On-site or remote, and in which languages?

On-site by default, because looking over a shoulder is most of the value, and remote when a team is spread across offices. Sessions run in English or French, and a mixed room is fine: we teach in the language the team works in, and the material follows. Extra languages in the room are one of the things that move the price off the floor.

Do participants get a certificate?

No, and that is deliberate. A certificate proves attendance, which nobody was in doubt about. What people leave with is the work itself, saved in their own accounts, plus a before-and-after number on real tasks. If you need something for a training record, we write what each person built and what moved, which is a stronger document than a badge.

What does IT need to do before the session?

Make sure every seat can reach the tools on the day: accounts provisioned, licences assigned, and the usual blocks lifted for the people attending. We send the list a week ahead and check it before travel, because a morning lost to access requests is a quarter of a training day gone. Where a tool is genuinely blocked by policy, we work in what is approved rather than around it.

How do you prove the training actually worked?

The same way we run a pilot: a dated read before, the same tasks scored again after. It is deliberately narrow, the real work the team does, timed and graded, so the comparison holds up outside the room. Where a team wants a longer view, we re-run the read a month later against the same tasks and you can see what stuck and what quietly reverted.

ConsultingAdoption, governance, and the practice around the tools→MethodThe baseline-and-measure discipline, applied to pilots→

Related work

What this looks like in practice

Three deployments where adoption was the hard part: a support team shown the escalation rules before anything was built, brand managers who defined the voice, and a CEO who had to trust the numbers.

All case studies→

Related reading

Go deeper on this

Field notes and method write-ups from the same work, tested before we published them.

All insights→

Talk to us

Talk to us about AI.

A conversation with the senior team about your teams, the tasks that eat their week, and whether training would actually change how they work. Tell us who would be in the room and we will tell you which track fits, or that a short skills read is the right place to start. No slides, no obligation, and if the honest answer is that your teams do not need a program, you will hear that too.

Contact us→

or hello@bearingbridge.com