The practice exists on the org chart and not yet in the programs
A prime stands up an AI practice for good reasons. Customers are asking, competitors are claiming, and the technical volumes need content that a systems engineering organization cannot write on its own. Eighteen months later the practice has a leader, a charter, a slide library, an internal governance policy and a handful of pilots that never left a sandbox. Meanwhile the programs that would benefit from it have hired their own data scientists, built their own pipelines, and stopped asking. That failure mode is common, and it is not a leadership problem. It is a structural one, and it has a specific cause: a practice that produces documents rather than deployed components has nothing the programs can use.
This is written for the chief technology officer or practice lead responsible for making the practice matter to the programs. The argument is that a center of excellence earns its existence by shipping reusable engineering assets and by putting engineers who have deployed inside agencies onto real programs, and that a specialist partner is the fastest way to get both without a hiring cycle that runs longer than the patience of the business.
Why staffing an internal AI practice is genuinely hard
Every prime running this play encounters the same three constraints, and understanding them is what keeps the plan realistic.
The people who can do this work have narrow, current, federal-specific experience. The skill is not machine learning in the abstract. It is having taken a system through an agency's environment: the boundary, the control inheritance, the assessor's questions, the data agreement, the accessibility review, the deployment pipeline inside a restricted network. That combination is uncommon, and the people who have it are usually mid-program somewhere.
The compensation and career structure fight the hire. A senior engineer who wants to stay an engineer needs a technical ladder that goes somewhere. Organizations built around program management structures often do not have one that reaches high enough, so the hire either does not close or leaves within two years for a firm where it does.
The practice is funded from overhead, which makes it perpetually contestable. Every quarter the practice's budget competes with things that have revenue attached. A practice with a slide library loses that argument. A practice that can point to three programs where its components are running, and two proposals where its demonstration was the discriminator, wins it.
The consequence is that the practice needs to show program impact before it can fund the headcount that would produce program impact. That ordering problem is the real one, and it is what a standing specialist partner solves: capability now, at variable cost, while the internal team is built deliberately around the work rather than ahead of it.
What makes an internal AI practice matter to the programs
Editorial weighting, illustrative rather than measured. The last row is deliberately low: policy is necessary and is not what makes a practice used.
The asset library, described concretely
A center of excellence that ships produces a small number of components that programs adopt because adopting them is faster than not. Vagueness here is fatal, so it is worth naming what those components actually are.
A document ingestion and extraction service
Not a script. A service with a stable interface: submit a document, receive structured output with a confidence score per extracted element, a provenance record naming source, page and bounding region, and a routing decision for anything below threshold. Behind it, document classification so scanned forms and native text take different paths, layout-aware extraction that preserves table structure and reading order, and a pluggable model layer so a program can substitute a different extractor without rewriting its callers. Programs adopt this because every federal program has documents and none of them wants to solve this again.
An entity resolution component
Blocking, pairwise scoring with field-specific comparison logic, clustering with explicit transitivity handling, and an adjudication queue with a user interface for the ambiguous middle. The reusable part is the machinery; the per-program part is the blocking strategy, the comparison weights, and the threshold policy. Shipping the machinery cuts a program's resolution effort by most of its duration, and the adjudication interface is the piece programs are most likely to underestimate and least likely to build well.
Evaluation infrastructure
The component with the widest reuse and the least glamour. A component that takes a versioned evaluation set, runs the program's model against it in continuous integration, computes metrics sliced by whatever categories the program registers, compares against thresholds, fails the build when a metric regresses, and emits a report in a fixed format. Add input distribution monitoring so drift is caught on the way in. Once a program has this, every conversation with its customer about model performance is grounded in something reproducible, and every oversight question has an answer already computed.
A deployment baseline with control inheritance worked out
Infrastructure as code for the target hosting environments the prime's programs actually use, with the boundary drawn, logging and audit paths defined, encryption configured, and a documented mapping of which controls in the NIST SP 800-53 catalog the baseline satisfies, which are inherited from the platform, and which remain the program's responsibility. This is the asset that saves the most calendar, because the control mapping is expensive work that every program otherwise repeats from scratch.
A demonstration shelf
Three or four working demonstrations on public corpora of the shapes the prime's markets care about, each with measured results, a stated method, and a reference architecture. Kept current, not archived. When a task order or an RFI appears with two weeks to respond, the demonstration shelf is the difference between showing something and describing something.
The engineering standard that makes a component reusable
Most internal component libraries fail not because the components are bad but because adopting them is harder than writing something new. Reuse is a design property, and four things produce it.
A stable interface with a version contract. Programs will not depend on something that changes under them. Semantic versioning, a deprecation policy with a stated window, and no breaking change without a migration path.
Deployable without the practice's involvement. If adopting a component requires a conversation with the team that built it, adoption stops at the second program. Documentation that lets a competent engineer stand it up from a clean environment, a working example with sample data, and a test suite the adopter can run.
No hidden environment assumptions. A component that only runs in the environment where it was born is not a component. Configuration external to code, no assumed network topology, no assumed identity provider, and explicit statements about what it requires from its host.
An owner who answers. Somebody responds to issues within a stated time. Without that, the first program to hit a bug forks the code, and the library becomes five divergent copies within a year.
These are ordinary software engineering disciplines. They are listed because internal practices staffed by data scientists rather than by software engineers routinely skip all four, and the resulting library is a collection of notebooks nobody can deploy.
Three ways to stand up the capability, compared
| Dimension | Hire the practice first | Draw from program staff | Specialist partner plus a small core |
|---|---|---|---|
| Time to first deployed component | Recruiting cycle plus ramp, typically three to four quarters | Fast on paper; programs rarely release their best engineers | Weeks, with the first increment against a real program |
| Cost profile | Fixed overhead from day one, contested every quarter | Charged to programs; creates schedule friction there | Variable, tied to increments, converting to headcount as demand proves |
| Federal deployment experience | Whatever the market yields at the offered band | Present but scarce and already committed | Present from the start; transferred deliberately |
| Effect on programs | None until the team is productive | Negative in the near term; capacity is removed | Positive early if the first increment serves a live program |
| Where the knowledge ends up | Internal, if retention holds | Internal, spread thin | Internal, if the agreement requires transfer as a deliverable |
| Typical failure mode | Practice produces policy and pilots; programs stop asking | Programs resist and the practice never reaches critical mass | Dependency, if transfer is not written into the agreement |
The third column carries one real risk and it deserves naming rather than hiding: a practice can outsource its way into permanent dependency. The defense is contractual and simple. Every increment names a receiving engineer inside the prime, every component ships with the documentation and tests that make it independently deployable, and transfer is a condition of acceptance rather than a favor afterward.
How we work inside a prime's AI practice
Precision Federal builds AI systems, data platforms, cloud infrastructure and full-stack web and mobile software, and delivers them into production inside federal agencies. Inside a prime's practice we work as a specialist subcontractor on three tracks at once, and most engagements start with one of them.
Components. We build the asset library items described above as production software with stable interfaces, tests, documentation and deployment examples, delivered as fixed-price increments against written acceptance criteria. Acceptance means a named engineer at the prime deployed it from a clean environment following the documentation, without our help.
Embedded engineers. We put named engineers onto the prime's programs at stated allocations, working inside the program's process and reporting to its technical leadership. This is a committed team arrangement rather than a defined-result one, priced accordingly, and it is how the practice's components meet real programs early enough to be shaped by them.
Capture support. We build the demonstrations, write the technical architecture content, and produce the measured results that capture teams use in RFI responses, technical volumes and oral presentations. This work happens at risk before award, and it is where a specialist earns the workshare that follows.
The prime keeps everything. All code, infrastructure definitions, evaluation sets, documentation, demonstrations and control mappings are assigned to the prime by present written assignment, with our pre-existing tooling named, excluded, and licensed back perpetually so the practice is never blocked on maintenance. We are a small business, which is relevant where subcontracting goals apply to the prime contracts the components run on. Customer relationships stay with the prime in every case, on programs and in capture.
The first step is one email with a one-page brief: what the practice is chartered to do, which programs would use the first component, the target hosting environments, what exists today, and the date that matters. We return a scoped, priced statement of work.
How to measure a practice so the measurement is honest
Practices are often measured by activity: pilots run, policies published, people trained. Those numbers rise while nothing ships. Four measures resist that.
Components deployed on programs, counted by program rather than by component. One component on four programs is a practice. Four components on one program is a project.
Weeks saved, estimated by the receiving program rather than by the practice. Ask the program's technical lead what it would have cost to build the component. The number is soft and the direction is honest, and asking creates the relationship the practice needs anyway.
Pursuits where the practice's material appeared in the technical volume. Not "supported", which means a review comment. Appeared: an architecture, a demonstration, measured results, a named engineer as key personnel.
Engineers who moved from the practice into program roles and stayed. That flow is the practice functioning as a talent pipeline, which is one of its most defensible justifications at budget time.
First-year priorities for a practice that intends to be used
Editorial weighting, illustrative rather than measured. The last row is deliberately low: maturity models describe practices that already ship.
Governance that helps rather than blocks
Practices are usually asked to own AI governance for the business, and the way that assignment is discharged decides whether programs treat the practice as an ally or an obstacle. Governance written as a review board that programs must pass creates avoidance. Governance delivered as infrastructure gets adopted.
The delivered form looks like this. The evaluation component produces the performance evidence, so a program satisfies the reporting requirement by running its pipeline rather than by writing a memorandum. The deployment baseline carries the logging and audit configuration, so the audit trail exists because the program used the baseline. The model description is generated from the pipeline metadata rather than maintained by hand, so it cannot drift from what is deployed. The review board then reads generated artifacts instead of asking programs to produce them, and the review is short because the evidence is already in a known format.
That inversion, governance as a byproduct of using the practice's tools, is the single highest-return design decision available to a center of excellence, and it is only available to a practice that ships software.
What the first ninety days should produce
A practice gets one credible opening. Spending it on strategy documents is how the credibility is lost, because the programs read that as the practice organizing itself rather than helping them. A sequence that builds standing looks different.
Weeks one to three: find the program that needs something now. Not the program with the most interesting problem. The program with a near-term deliverable that a component would materially help, and a technical lead willing to accept help. Sit with that lead, understand the deliverable, and scope a component that serves it. The practice's first customer being a real program with a real date is what converts the charter into standing.
Weeks three to eight: build and deploy one thing. One component, production quality, with tests, documentation, an example, and a version number. Deployed on that program, by that program's engineers, following the documentation. Resist the urge to generalize it first. A component built for one program and then generalized is reusable. A component designed for reuse before anyone used it is a framework nobody adopts.
Weeks six to twelve, in parallel: stand up the evaluation infrastructure and the first demonstration. The evaluation component because it has the widest reuse and the shortest path to being inherited by a second program. The demonstration because capture will ask, and because the practice that answers a capture request in three days rather than three weeks becomes the practice capture calls first.
Throughout: publish what shipped, not what is planned. A short internal note per increment naming the component, the program running it, the engineer who deployed it, and what it replaced. That record is what the practice takes into the budget conversation, and it is far more persuasive than a roadmap.
Where the practice and the programs are likely to collide
Two frictions are predictable and both are manageable if they are anticipated.
Programs do not want a dependency they did not choose. A program manager accountable for a delivery date is right to be cautious about depending on a component owned by an overhead-funded team with its own priorities. The answer is a service level the practice actually commits to: a response time on issues, a support window, and a stated policy that a program may fork with the practice's help if the practice cannot meet a need in time. Offering the fork explicitly is what makes the dependency acceptable, and it is rarely exercised once offered.
Program engineers resist components they did not write. Sometimes this is territorial and often it is well founded, because they have seen internal libraries that were abandoned. The counter is evidence: a test suite they can run, a clean deployment they perform themselves, and a second program already using it. Bring the engineer into the design of the next version rather than arguing about the current one. A program engineer who contributed to a component defends it internally in a way no amount of advocacy from the practice achieves.
Bottom line
An AI center of excellence inside a prime is judged by whether programs use it, and programs use components rather than documents. That means shipping a small number of production-quality assets with stable interfaces, tests and deployment documentation, putting engineers with federal deployment experience onto live programs early, and keeping a demonstration shelf current for capture. The constraint is staffing, and it runs longer than the practice's political runway. A specialist partner supplies the capability now, at variable cost, while the internal core is built around work that already exists. Write transfer into every increment, measure the practice by deployments on programs rather than by activity, and deliver governance as infrastructure rather than as a gate.
Frequently asked questions
Usually because they produce documents and pilots rather than deployable components. A program under schedule pressure adopts something only when adopting it is faster than building its own, which requires a stable interface, documentation good enough to deploy from a clean environment without help, a test suite the adopter can run, no hidden environment assumptions, and an owner who answers issues. Practices staffed with analysts rather than software engineers tend to skip all of those, and the library becomes notebooks nobody can deploy.
A document ingestion and extraction service with per-element confidence and provenance; an entity resolution component including the adjudication interface; evaluation infrastructure that runs in continuous integration and fails a build on regression; and a deployment baseline with the control inheritance mapping already worked out for the hosting environments the programs use. The evaluation and deployment assets have the widest reuse and save the most calendar, because every program otherwise repeats that work from scratch.
Write transfer into the agreement rather than treating it as goodwill. Name a receiving engineer inside the organization for every increment. Make acceptance mean that engineer deployed the component from a clean environment following the documentation, without help. Require tests, runbooks and infrastructure definitions as deliverables rather than as follow-on work. And take a present written assignment of the code, with the partner's pre-existing tooling named, excluded and licensed back perpetually so maintenance is never blocked.
By deployments on programs rather than by activity. Count components running on live programs, counted by program rather than by component. Ask the receiving program's technical lead what building it themselves would have cost. Count pursuits where the practice's architecture, demonstration or measured results appeared in the technical volume, not pursuits it merely reviewed. And count engineers who moved from the practice into program roles and stayed, because that flow is one of the practice's strongest justifications at budget time.
It can, provided it is delivered as infrastructure rather than as a review gate. When the practice's evaluation component produces the performance evidence, the deployment baseline carries the logging and audit configuration, and the model description is generated from pipeline metadata rather than maintained by hand, a program satisfies governance by using the practice's tools. The review board then reads generated artifacts instead of asking programs to produce them, and programs stop routing around the practice.