A mixed team from two companies, one AI delivery workflow, and a rule that has not moved: a person approves every change.
With CAIT.tech and Claude, Immigration Pathways:
- delivers up to twice as many features in the same time, with development time per task 30 to 50% shorter
- cut the path from ticket to release branch from five days to three or four
- spends four to six times less time on story and task refinement, with the planning agent writing the task descriptions
- kept rework after QA at the same 15 to 20% while moving faster
- keeps every pull request approved by a person, enforced by the platform
About Immigration Pathways
Immigration Pathways is a platform for people going through the US immigration system. An applicant runs a free eligibility check, sees which routes are worth exploring (H-1B, O-1, EB-2 NIW, a J-1 waiver, a family petition), and is introduced to an attorney with verified credentials in that category. From there the case sits in one place: documents, forms, family members, contracts, payments, status. Attorneys open the same case from the other side.
TIAC builds the platform together with Immigration Pathways in a mixed team drawn from both companies. Since Q3 2026 that team has worked on CAIT.tech, TIAC's AI delivery platform built on Anthropic's Claude models.
One thing to set out first, because the subject invites the question. This is about how the software is built. Assessing a case and advising on it is legal work, it belongs to the attorneys on the platform, and nothing described here touches it.
A year of good individual AI use that did not add up
For most of the first year, everyone on the team used AI the way the industry has been using it: individually. Each developer chose their own tools, wrote their own prompts and built their own skills. Claude Code was the most common choice, though never the only one.
That was a reasonable way to begin. The tooling was changing month to month, and letting engineers find what worked was a sensible response to that. It also worked. Nobody on this team needed persuading that AI was worth using, and the product was being built well throughout.
What the arrangement could not do was accumulate. A prompt someone refined over an afternoon stayed with that person. A skill written for a recurring part of the codebase lived in one local setup. Two companies working one repository meant two sets of habits and two sets of tool preferences, with nothing in the arrangement bringing them together.
Both sides arrived at the same reading at roughly the same time. The work was good, and none of it was compounding.
The tools were never the issue. What we got back was everyone's work in one place, which is the part we could not build ourselves out of individual habits.
Engineering leadership, Immigration Pathways
Choosing Claude for planning, code and review
Claude was already the tool most of the team reached for before the change, through Claude Code on individual setups. When TIAC built the shared workflow on CAIT.tech, Claude models became the engine behind every agent, called directly through the Anthropic API with no intermediate gateway or reseller.
The agent set assigns models by task and runs Claude models from version 4.8 onward, currently Claude Fable 5.1, Claude Opus 5.5 and Claude Sonnet 5. Claude Fable and Claude Opus handle AI readiness analysis, planning and plan review. Claude Opus and Claude Sonnet run the implementation, code review, QA and delivery agents. The team moves to each new model release as it becomes available. Developers also use Claude Code alongside the platform for research and exploratory work that falls outside the agent workflow.
Everything up to go-live ran on TIAC's own resources and TIAC's own Anthropic account. Immigration Pathways' key carries production consumption and nothing before it.
CAIT.tech uses prompt caching for the context every agent shares, the codebase and the task specifications, so repeated calls reuse that context instead of sending it again. Consumption on Immigration Pathways' key stays predictable and well below what the same work would cost without caching, and responses on long contexts come back faster.
One shared workflow, with a person approving every change
TIAC configured a CAIT.tech project profile inside Immigration Pathways' environment. That covered access for the team, Immigration Pathways' own Anthropic organisation API key, integration with their Redmine, Bitbucket and IDE, the planning, implementation, code review and QA agents, and a skills library set against the product's coding and security standards. The team was trained, Immigration Pathways confirmed acceptance, and the platform went into production use in Q3 2026.
Agents connect to Redmine, Bitbucket and the developers' local environments through Model Context Protocol (MCP) servers, so every agent retrieves context through one standardised, access-controlled interface.
The library is what answers the original problem. Prompts, skills and agents are captured, versioned and searchable in one place, so an approach worked out once is available to everyone on the project from then on.
How delivery runs on CAIT.tech: agents support every step from backlog to product increment, while people approve the plan, lead code review and QA, and give final acceptance.
Human approval is the fixed point
A product in this category can work with agents because the control structure came first.
Every pull request is approved by a person. That is a constraint in the platform itself, so it holds under deadline pressure rather than depending on anyone's discipline. Automated quality gates score changes before they reach review. Agent actions are logged and traceable. Access runs through SSO with role-based permissions. Agent versions are pinned, so behaviour changes when the team decides it changes and never underneath them. Models are called on Immigration Pathways' own Anthropic organisation key, with consumption reported at team and project level, and the platform does not run without that key.
CAIT.tech was designed around EU AI Act and NIST AI RMF expectations from its first version, so none of this was assembled for this engagement. TIAC's phrasing for the principle is AI-first, human-led. Agents assist, automate and augment. People lead, decide and own the outcome.
We were going to use agents only if the approval structure stayed exactly where it was. Every change still goes past a person. That was the condition, and it is still the condition.
Engineering leadership, Immigration Pathways
Keeping up with the rules
US immigration rules move. Forms get revised, thresholds shift, a category changes what it accepts as evidence, and a platform that organises cases has to follow.
Immigration Pathways does not leave that to whoever happens to notice. Tracking the rules belongs to the people accountable for it, supported by systems that flag changes, and there is more than one route by which a change is caught. What reaches engineering is a task: this changed, here is what the product needs to do about it.
That division puts weight on the task itself, and agents raise it further. A developer who did not discover the change works from how it was written down. An agent has less still, because it fills nothing in from context it was never given. So requirements on this product are written to carry what a conversation used to, and the change then travels the same path as everything else: built, reviewed, approved by a person, shipped.
The planning agent carries much of that weight: it writes each task in enough detail that the developer, and the agents after it, have what the change requires.
Up to twice as many features, with quality held
The figures below cover every task with a coding component that the developers completed in the first three weeks of production use, compared with how the same team worked before the switch.
- Development time on a task is 30 to 50% shorter, so the team delivers up to twice as many features in the same time.
- The full path from writing a ticket to merging the change into the release branch fell from five days to three or four. Features are then grouped into releases for production.
- Story and task refinement takes four to six times less time. The planning agent writes the task descriptions, and they come out more detailed than the ones the team wrote by hand or with individual Claude tools, with fewer gaps left to fix later.
- Rework after QA held at 15 to 20% of changes, the same level as before, so the gain in speed came with no loss in quality.
On tasks with tightly defined descriptions and acceptance conditions, agents produce around 90% of the code. On more complex tasks the share is 50 to 60%. All of it reaches the product through a pull request that a person approves.
Work that used to take us a full working week now reaches the release branch in three or four days, and nothing gets there without one of us approving it.
Engineering leadership, Immigration Pathways
What the change asked of both sides
Neither side got through the change for free, and both costs were foreseeable.
For the developers, giving up a personal setup refined over a year is a real ask even when the replacement is better. Working the same way as everyone else took time to feel natural.
For TIAC, standing the platform up was familiar work. Tuning the skills and agents to this product's standards was not difficult and it was not quick either, and that is the part to budget for on any rollout of this kind.
Standing the platform up is routine for us. Getting the skills and agents to match how this product is actually built is where the time goes, and it is time worth spending.
TIAC R&D
Building on the shared library
The platform is in production use, with production support and consumption reporting running under a Statement of Work that extends to Q3 2027. The agent set continues to develop, with existing agents updated and new ones added as the work demands.
Business analysis still runs outside the platform for now. A BA agent is in testing, and its output is being checked for quality. Once it meets the team's bar, business analysis moves onto the platform as well, and the whole path from requirement to release runs through one shared workflow.
