We started this because most "AI agent" projects don't ship.

Aratavan was founded by a small group of engineers who had, between them, sat through more "AI transformation" kickoffs than any of us wanted to admit, as vendors on one side of the table and, at a few points, as the frustrated client on the other. The pattern was consistent enough that it started to feel less like bad luck and more like a structural problem with how the industry sells this work.

The problem we kept running into

Here's roughly how it went, more times than not: a company decides it wants "an AI agent" for something: support, sales, ops, whatever the pain point of the quarter is. They bring in a vendor. The vendor is excited, the client is excited, everyone agrees this is going to change things. Then the scoping starts, and it never really stops. The workflow turns out to be more specific than the pitch deck implied. The vendor wants to build a platform, not a solution to the one problem in front of them, because the platform is what they can resell to the next client. Timelines get "refined." Budgets become retainers. Eighteen months later there's a working demo that has never touched a real customer, and the person who championed the project internally is quietly looking for a new job.

None of this is really about the technology. Large language models are good enough, right now, to handle a large share of the workflows that get pitched as "AI agent" projects. The failure mode is almost always commercial and organizational: open-ended engagements don't have a forcing function to actually finish, and vendors whose revenue depends on ongoing retainers have a quiet incentive not to.

"We didn't set out to build a company around a pricing model. We set out to fix the actual failure mode, and the pricing model was just what enforcing that discipline required." Founding notes, internal planning doc, year one

Why fixed scope, fixed price, fixed date

The constraint is the point. When we quote a fixed price and a fixed delivery date before writing any code, three things happen that don't happen in an open-ended retainer:

• The scoping conversation gets serious, fast. If we're going to be held to a number and a date, we need to actually understand the workflow: every input, every system it touches, every case where a human currently has to make a judgment call. Vague scoping produces vague builds; a fixed quote is a forcing function against vagueness on both sides of the table.
• There's no incentive to keep the engagement open. We get paid to finish, not to keep meeting. A retainer model quietly rewards the vendor for the engagement lasting longer; a fixed-scope model rewards us for shipping and moving to the next one.
• You get a real decision point, not a slow bleed. If the quote is too high for the value, you find that out on day two, not month eight. That's a better outcome for you even when the answer is no.

What this means we say no to

We turn down more scope calls than we accept. Specifically, we won't quote a fixed price against:

• A goal instead of a workflow. "Help our customers succeed" isn't scopeable; "resolve return requests under $75 without a human" is.
• A workflow the client can't currently describe in specific steps, because if you can't describe it, we can't build against it, and the resulting agent will disappoint everyone.
• Fully autonomous decision-making on irreversible financial, medical, or legal outcomes with no human checkpoint. We'll build the triage, the drafting, the first-pass review, the part that removes 80% of the manual load, and leave the final call with a person, because that's where it belongs today.
• A budget that isn't proportional to the scope. If the described work is nine months and the budget is a fortnight, the honest answer isn't a cheaper version of the same promise, because no such thing exists. We'll tell you what the scope as written actually costs. Where a genuinely smaller first build would answer the question you're really asking, we'll quote that instead and say plainly what it leaves out. What we won't do is take the money and hand back something described as finished that isn't.

Saying no on a scope call costs us a sale. We do it anyway, because the alternative is delivering something that technically shipped but shouldn't be trusted, and that's a worse outcome for everyone with our name on it.

Who actually does the work

Every engagement is staffed by engineers who have shipped production systems before agents were the thing to build: people who came up building payment infrastructure, clinical scheduling systems, logistics routing engines, and internal tooling at companies where a bug meant a real, immediate consequence, not a bad demo. That background is why the scoping calls tend to ask uncomfortable questions early: what happens when the API is down, what happens when the input is malformed, who gets paged when the agent gets it wrong. Those questions are cheaper to answer on a scope call than after go-live.

What we're building toward

We're not trying to become a platform company, and we're not trying to make ourselves obsolete by selling you a no-code builder you'll never touch. We're trying to be the team you call when you have a specific, well-understood workflow that's expensive in people-hours and boring enough that a person doing it all day is a waste of what they're capable of, and you want it handled by someone who will tell you honestly whether it can be done, what it costs, and when it'll be done, and then actually be right about all three.