Immigration Pathways and TIAC move a year of individual AI use onto one shared workflow

Read time
5 min
Category

Immigration Pathways and TIAC move a year of individual AI use onto one shared workflow

The team had worked with AI tools daily for more than a year, and worked with them well. What none of it produced was anything the next developer could pick up.

13+ months of continuous development before the change

One workflow planning, implementation, review and QA on a single platform

Immigration Pathways is a platform for running immigration cases, connecting applicants with immigration attorneys. TIAC d.o.o. Novi Sad, a partner in the Claude Partner Network, builds it together with the client in a mixed team. Team works on CAIT.Tech, TIAC's AI-augmented delivery platform built on Anthropic Claude models, with the client's Jira, GitHub and IDE environments connected and every agent action logged.

One case, in one place

An applicant enters and manages their personal and immigration data, explores the options open to them through Ellis, the platform's AI feature, and is put in contact with the right attorney when the case calls for one. From there everything that belongs to the case sits together: documents, forms, family member records, contracts, payments, and the current status of the application. Attorneys work the same cases from the other side, reviewing client data, documentation and forms and following each case as it moves.

Immigration work is normally spread across email threads, government portals, scanned paperwork and phone calls, and an applicant rarely knows which piece matters next. Holding the whole case in one structured, visible process is what the product is for.

Good adoption, nothing shared

A year of AI use that stayed inside individual sessions

The team had been working with AI tools for most of the product's development. Claude Code was the main one, alongside others that individual developers preferred. Adoption was never the obstacle here, and nobody needed convincing that the tools were worth using.

What stayed with the individual was everything about how that use worked. A prompt someone spent an afternoon getting right lived in that person's session. An approach to a recurring part of the codebase existed once, in one head. When a second developer met the same problem three weeks later, there was nowhere to look it up, so they solved it again and paid for it again.

A mixed team sharpens that. TIAC's engineers and the client's engineers work the same codebase from two organisations with their own habits and their own tooling choices, and nothing in the setup pushed those together.

On a product past its first year on one codebase, the cost of this is quiet and cumulative. The team's understanding of its own product was real and it was growing, and it was accumulating in places the team could not reach.

[Proposed: We were never short on AI. Every developer had a setup they liked and most of them were good. What we could not do was hand any of it to the next person.]
[Name], [Title], Immigration Pathways

What changed

No incident prompted the move. The decision was about compounding: the same work, arranged so that what one person figures out stays available to everyone who comes after.

TIAC configured and integrated a CAIT.Tech project profile in the client's environment. That covered platform access for the teams, connection of the client's own Anthropic organisation API key, integration with the client's Jira, GitHub and IDE environments, configuration of the planning, implementation, code review and QA agents, and a skills library aligned to the product's coding and security standards. The teams were trained, acceptance was confirmed, and the platform went into production use in Q3 2026.

Up to go-live, TIAC carried out all configuration, integration and testing on its own resources and its own Anthropic account. No Claude model consumption was billed to the customer before the platform was in production.

The agents sit inside the delivery process

CAIT.Tech's agents run in the tools the team already uses, across four stages:

01   Planning.  Reads the requirements, documentation, codebase and history before work starts, proposes a decomposition with tasks, estimates and test scenarios, and flags gaps, risks and inconsistencies while they are still cheap to fix.

02  Implementation.  Writes code and tests, refactors, runs and debugs, and keeps documentation current as part of the same loop.

03  Code review.  Goes through changes for quality, security, standards and anti-patterns before a human opens the pull request.

04  QA.  Writes test cases, runs regression, and reports defects and the areas carrying the most risk.

Underneath all four sits the skills library: prompts, skills and agents captured, versioned and searchable. That is the part answering the original problem. An approach worked out once stays available to whoever needs it next, and the team stops paying repeatedly for the same answer.

Where the control sits

Four things are fixed by design rather than by discipline.

01   Every pull request is human-approved.  This is a constraint in the platform, not a team convention that can slip under deadline pressure.

02   Agent behaviour changes when the team says so.  Versions are pinned, and upgrades happen on the team's schedule.

03   Everything is traceable.  Agent actions are logged, automated quality gates score the work, and access runs through SSO with role-based permissions.

04   Consumption is visible and it belongs to the customer.  Models are called on the customer's own Anthropic organisation key, with cost reported at team and project level. The platform does not operate without that key.

CAIT.Tech was built around EU AI Act and NIST AI RMF expectations from its first version, so none of this had to be retrofitted for this engagement. TIAC's own phrasing for the principle is AI-first, human-led. The agents assist, automate and augment; the human leads, decides and owns the outcome.

What gets harder

Two things change for the people doing the work, and TIAC says both out loud, because teams that hear only the encouraging half are surprised later.

Specification moves earlier

A thin user story is workable in traditional delivery, because a senior developer fills the gaps from experience. An agent fills nothing in. It builds on what it is given, which turns agent-ready requirements, current documentation and explicit architecture into preconditions for the work. The effort moves to the front of the process rather than disappearing from it.

Review gets heavier

More work arrives at the review step, and validating it takes deeper product knowledge than reading a colleague's code did. Senior review becomes the most consequential step in the process. Junior engineers, at the same time, take on broader scope sooner, owning development plans where they would previously have owned tickets.

Where it stands

The platform is in production use on Immigration Pathways, with production support and consumption reporting running under a Statement of Work that extends to Q3 2027. The agent set keeps evolving, with existing agents updated and new ones added as the work demands.

For TIAC, the engagement answered a question worth asking. A team that had already adopted AI well, on its own initiative, over more than a year, still had everything to gain from putting that use somewhere shared.

[Proposed: What we watched for was whether the control we already had would survive the change. Every pull request still gets approved by a person. That was the condition for going ahead.]
[Name], [Title], Immigration Pathways

Milan Vunjak

Senior R&D Associate