The questions we get asked before every engagement

Production AI systems, not prototypes. In practice that means four kinds of work: autonomous agents that execute a business process end to end, retrieval-augmented generation systems that answer questions over a company's own documents with citations, LLM features embedded inside an existing product, and the evaluation and observability layer that tells you when any of the above starts failing. We also do short scoping engagements for teams that are not yet sure which of those they need.

With a 30-minute technical call, then a paid two-week scoping sprint. The call is with an engineer, not a salesperson, and its only purpose is to work out whether the thing you want is feasible and worth doing. The scoping sprint produces a written architecture, an evaluation plan, a cost and latency model, and a build estimate. You own all of it whether or not you continue with us — that is deliberate, because a scope you cannot take elsewhere is not a scope, it is a lock-in.

Six to ten weeks for a first agent or RAG system in a typical mid-size company, measured from the end of scoping to real users on real data. The variable is almost never the model work — it is data access, security review and deciding who signs off on the agent's decisions. Engagements that stall usually stall on those three, which is why we surface them in week one rather than week six.

Model behaviour drifts, providers deprecate versions, your data changes shape and usage patterns move. Systems we operate get monitored evaluation runs, cost and latency dashboards, alerting on quality regressions, and a monthly review of where the system is degrading. Clients who take the handover and run it themselves get the same tooling and a walkthrough of how to read it. What does not work is launching and looking away for six months.

Yes, and it is the more common arrangement. We embed with your engineers, work in your repository, follow your review process and hand over with documentation and a recorded walkthrough. The goal is that your team can extend the system without us. If you would rather we own a component outright and deliver it as a service, we do that too, but we will always tell you which of the two is cheaper for you over two years.

Delivery is led from Bengaluru with a four-hour daily overlap with US Eastern hours, and a US entity for contracting, invoicing and on-site work when a client needs it. Standups happen in the overlap window, and async written updates cover the rest. For teams on US Pacific time we shift the overlap later in the Indian day. The practical effect is a working day that is longer than either team's, not shorter.

Often you should, and we will say so. Hiring makes more sense when AI is going to be a permanent core competency, when you have eighteen months of runway to get the first system right, and when you can compete for the talent. Bringing us in makes sense when you need the first system working this quarter, when the failure modes are unfamiliar and expensive to learn on live traffic, or when you want your own engineers trained by working alongside people who have already made those mistakes.

A two-week scoping sprint, or a one-week technical audit of an AI system that is already misbehaving. Below that there is not enough time to understand the domain well enough to be useful, and you would be paying for our learning curve. If your question is genuinely small, the first call is free and we will often just answer it.

Scoping sprints are fixed price. Build work is priced per milestone against the scope produced in that sprint, and ongoing operation is a monthly retainer sized to the number of systems under management. We avoid open-ended time and materials on new builds because it puts the risk of a bad estimate on you rather than on us. Exact numbers depend on scope and region, and we will give you a range on the first call rather than after three meetings.

Whichever fits the constraint. Most production systems we run use a frontier model from Anthropic or OpenAI for reasoning-heavy steps and a smaller or open-weight model for high-volume classification and extraction, because paying frontier prices for routine work is the most common source of unnecessary AI spend. We build behind a provider abstraction so a model can be swapped without touching business logic, and we benchmark on your data before committing to one.

You cannot eliminate wrong answers from a language model, so the engineering problem is containing them. In practice: retrieval grounded in your own sources with citations the user can open, structured output validated against a schema before anything acts on it, confidence thresholds that route uncertain cases to a human, and an evaluation suite built from your real historical cases that runs on every change. The measurable target is not zero errors — it is a known error rate with a known escalation path.

It stays in your infrastructure wherever the architecture allows. Our default pattern is to deploy inside your cloud account or VPC, use zero-retention API configurations with model providers, and keep all embeddings and logs in storage you control. We sign NDAs before technical discussions and work under your DPA. For teams with residency requirements — Indian DPDP Act, EU GDPR, US healthcare data — we design to the constraint from the start rather than retrofitting it.