The Short Answer
An AI engagement is bounded when the platform being integrated is already finished; ceilings and change control are what you install when it is not. On ibl.ai the base exists and you own all the code and the data, so scope is integration against named systems. It is model-agnostic with no per-seat pricing, and deploys anywhere, including fully air-gapped.
Every AI engagement arrives with governance attached: a ceiling price, a change-control process, weekly burn reporting, phase gates, a steering committee.
All of it is sensible, and all of it is compensation. Those mechanisms exist because the scope is open, and they are how you manage an open scope responsibly.
They are not the same thing as a boundary.
What actually makes an engagement bounded?
That the thing being integrated already exists.
This is a property of the starting point rather than a project-management technique.
If a vendor is constructing permissions-aware retrieval, an evaluation harness, guardrails, role-based access control, audit logging and model routing during your engagement, the scope is genuinely unknowable — not because the team is undisciplined, but because nobody has designed the system yet.
Federal acquisition regulation says this explicitly. FAR 16.601 permits time-and-materials contracting only where it is not possible to accurately estimate the extent or duration of the work — which is an accurate description of building a platform from nothing.
By contrast, connecting a finished platform to a named list of systems is ordinary integration work. It has a beginning, a definable end, and an estimate an experienced team will stand behind.
How do you tell which one you are buying?
Ask what specifically is being built in month four.
If the answer describes your data model, your workflows, your agents, your integrations — that is bounded work on a finished base, and the estimate deserves confidence.
If the answer describes retrieval, evaluation, guardrails, access control or audit logging, the engagement is constructing the foundation.
Every governance mechanism in the contract is then managing an open scope, and the outcomes match: 79% of enterprises reported AI cost overruns in the past twelve months, with 80–85% missing infrastructure forecasts by more than 25%.
A second question sharpens it: which of the capabilities we need do you already have running in production today? A platform vendor answers with a system. A services firm answers with a roadmap. Both answers are legitimate; they describe different purchases.
Do controls help on an open-ended engagement?
Yes, and they should be used — they simply cannot substitute for the thing they are compensating for.
A ceiling caps exposure without creating an incentive to stay under it, which is why FAR pairs the ceiling requirement with a surveillance requirement. Phase gates prevent a bad quarter becoming a bad year.
Weekly reporting against a held-out evaluation set, rather than against hours burned, distinguishes progress from motion.
Use all of them. Just recognise what they are: a well-managed open scope is still an open scope, and the most common outcome is reaching the ceiling and negotiating an increase because the underlying work is genuinely unfinished.
We wrote about that failure mode in Why AI Programs Reach the T&M Ceiling.
Does bounded mean less customization?
No — it means the customization is the whole engagement rather than the last phase of it.
This is the misconception worth correcting directly. Starting from a platform does not reduce how much bespoke work you get; it changes what the bespoke work is.
Instead of six months of foundation followed by a rushed quarter of anything specific to you, the engagement starts on your workflows.
Our forward-deployed engineers do genuinely custom work: agents for your processes, integrations against your systems of record, extensions to the platform in a fork you own.
The full source ships under a perpetual licence, so nothing about the customization is bounded by what a vendor is willing to expose.
What is bounded is the estimate — because the thing being extended is finished.
What does a bounded engagement look like in practice?
Weeks to a production workload, then continuous extension.
The platform is deployed on your infrastructure. Integration proceeds against a named endpoint list — your SIS, EHR, CRM, identity provider, document stores. Acceptance is measured against a held-out evaluation set drawn from your own data.
The first real workload serves real users while the programme still has its original sponsor.
After that the work does not stop; it changes character. New agents, new integrations, new workflows — each a defined piece against a base that already works, rather than another instalment of construction.
That is why an ibl.ai engagement is comparatively efficient: the platform runs today with 1.6M+ users from 400+ organizations, so the engagement is customization rather than a synonym for building the thing that should already have existed.
The contracting side is covered in Time & Materials for AI Infrastructure, and the estimate question in Time and Materials Is an Admission, Not a Pricing Model.