Consultant or agency: which model fits AI production work

When a company in Romania or anywhere else in Europe needs AI added to an existing production system, the sales conversation usually lands in one of two places: an agency with a team of specialists, or an independent consultant who builds the work themselves. Both models can deliver a working AI integration, and the difference shows up later, in how the work gets scoped, what gets delivered, and who you’re actually talking to at the moment something breaks.

I’ve spent seventeen years building production systems and the last few of those focused on AI pipelines, so I have a particular view on where each model fits. This post is the honest version of that view, not a sales pitch for either side.

What an agency is good at

An agency has multiple people, and that means access to specialized skills in parallel — someone focused on model tuning, someone on deployment infrastructure, someone on data pipelines. When a project genuinely needs expertise across several domains at the same time, that depth can matter. Agencies also handle parallelism well: if you need a proof of concept built for three business units simultaneously, they can assign separate teams to each track and the coordination overhead lives inside their organization instead of yours.

The tradeoff is that you’re not usually talking to the people writing the code. You’re talking to an account manager and a project lead, and communication passes through layers. Requirements get interpreted and then re-interpreted, and when you ask “why did this validation pass in staging and fail in production,” the answer takes a day to come back because it has to route through whoever actually built that piece. The cost structure reflects the same overhead — agencies price in account management, sales cycles, and bench time between projects, and retainer arrangements keep teams staffed whether you have active work or not.

What an independent consultant is good at

An independent consultant is one person doing the technical work, and that means the person scoping the project is the same person writing the code and handling deployment. When something unexpected surfaces during implementation, there is no handoff: the decision about whether to adjust the AI extraction logic or add validation at the pipeline boundary happens in the same head, in the same context as the rest of the system design.

The constraint is bandwidth. An independent consultant handles one engagement at a time, maybe two if the timelines interlock cleanly, and if you need four systems built simultaneously you’re either coordinating several consultants or waiting for sequential delivery. Pricing usually works as fixed scope — you define what gets built, you get a timeline and total cost, and that’s what you pay, with no retainer and no account management margin sitting on top.

Where AI work specifically pulls on this choice

AI systems introduce failure modes that don’t exist in deterministic software. The model returns malformed JSON, the classification confidence drops below threshold, or the extraction misses a required field because the input used phrasing the prompt hadn’t seen. These are not rare edge cases on a production pipeline, they are the daily reality, and whoever designs the system has to own where every one of those failures gets handled.

Agency work often separates “AI development” from “production engineering” — one team tunes the prompts and another team handles integration and observability — and that separation creates gaps. Who owns the retry logic when the model hits rate limits? Who decides whether validation happens before or after the model call? Who owns the behavior when the third-party API changes its response format? An independent consultant building the full pipeline owns every one of those boundaries because there is nobody else to own them. If Claude occasionally returns invalid JSON, the fix is not “file a ticket with the AI team,” it is adding schema validation right after the API call with retries and fallback logic in the same deployment.

A decision framework that actually helps

Pick an agency when you need multiple specialized roles working in parallel, when the project has to scale across several business units simultaneously, when you have internal teams that will own the system after delivery and prefer structured account management, or when the budget supports retainer-based pricing.

Pick an independent consultant when you need direct access to the person making technical decisions, when the work involves end-to-end pipeline ownership from ingestion through AI processing to structured output, when you want fixed-scope delivery with defined timeline and cost, and when you want to ask a question and get the answer the same day from the person who wrote the code.

The handoff question is worth its own thought. Agencies often structure ongoing support as a retainer — you keep paying monthly whether you need changes or not — which makes sense if you’re continuously evolving AI capabilities. An independent consultant typically delivers documented code with runbooks and observability, and then steps back. You run it, and if something breaks or you need enhancements later, you engage again for a defined scope.

The real question

It is not which model is better. It is whether your project needs direct technical ownership of every failure boundary, or whether it needs distributed specialized expertise spread across several workstreams. If you know which of those two shapes your project has, you already know which model to pick. If you’re unsure, that uncertainty itself is useful information — it usually means the scope is not yet defined clearly enough to price either way, and the first thing to do is define the scope, not hire the builder.