Build the runtime your auditor will accept.

What the team is actually building

The product is a runtime, not a chatbot. Six capabilities sit on it — agents, voice, workflow, WhatsApp, email and SMTP, and GEO — and they share contacts, consent, activity and billing. That sharing is the whole architectural bet: an Indian business does not want five tools that each hold a different version of the same customer, and it does not want five invoices in five formats with five support queues.

Building that means working on problems that are unglamorous and hard. Identity resolution across phone numbers and email addresses that Indian customers change often. Consent records that survive deletion. Latency budgets where 420ms is the median target and the last hundred milliseconds are the expensive ones. A pricing engine that adds 18% GST and issues a GSTIN invoice. A workflow canvas that a non-engineer can operate without breaking a payment path.

It also means shipping into production for real customers with real auditors. The line on the careers page, build the runtime your auditor will accept, is not a slogan about compliance theatre. It is a constraint on architecture: if a run cannot be traced, if a consent record cannot be produced, if a deletion cannot be explained, the feature is not finished. That constraint is what makes the engineering interesting, and it is also what makes it slower than a demo.

The four open roles, without embellishment

The forward-deployed agent engineer is a customer-facing builder. The job is to take one workflow from a scoping call to production in about 48 hours, then stay with it through the first month while the numbers settle. That means writing prompts that survive adversarial input, wiring tools, defining evaluation sets, and sitting on a call with a sales head who wants to know why a lead was routed to the wrong person. It is engineering with a customer in the room.

The product designer owns the surfaces an operator touches: the agent console, the workflow canvas, the shared inbox and the pricing calculator. This is infrastructure design, which is a different craft from marketing design. The screens are dense, the users are on calls while they use them, and the most important design decision is usually what to hide until it is needed. A portfolio of beautiful dashboards with no state model will not carry the conversation.

The Indic voice data lead runs a contract engagement covering the fourteen languages the platform supports. The work is script design, recording, annotation, quality review and the endless judgement calls about code-mixed speech: when a caller says a number in English inside a Marathi sentence, what should the transcript say. The enterprise account executive covers Mumbai and Bengaluru, selling into BFSI, real estate, healthcare and logistics buyers who will ask for a DPDP questionnaire before they ask for a discount.

A week in the life of a forward-deployed engineer

Monday is scoping. A customer has a workflow that half works, and the engineer’s job is to find the step where it actually breaks. That is rarely the step the customer names. A collections workflow that looks like a messaging problem is often an identity problem: the same borrower exists under two phone numbers, and the reminder goes to the one that was abandoned. The output of Monday is a one-page plan with a named owner on the customer side.

Tuesday and Wednesday are build days, and they are interrupted by design. The prompt is the easy part; the tool schema, the retry behaviour, the escalation rule and the data mapping take the time. Every build includes an evaluation set of at least thirty real cases pulled from the customer’s own history, including the ugly ones: the abusive message, the wrong number, the customer who writes in three languages in one sentence. If the build cannot pass those, it does not go live.

Thursday is go-live and Friday is the review. Go-live is deliberately boring: one channel, a small cohort, a human watching the first fifty runs. Friday is where the engineer earns their keep, because the first data usually contradicts an assumption. The most common finding is that the workflow is too broad, and the fix is to narrow it rather than to add another branch. Then the cycle repeats with the next workflow, usually with the same customer.

What a deployment actually contains

New engineers usually assume the job is mostly prompting. It is mostly plumbing. A deployment has a trigger, one or more tools, a data contract with the system of record, an escalation rule, a consent record and a run trace. Remove any one of those and the workflow becomes a demo that works until the first exception, at which point somebody turns it off and tells the team that AI does not work.

The data contract is where most of the week goes. The CRM has a field for last contact date, but it is updated by three different processes and one of them is wrong. The customer’s product catalogue lives in a spreadsheet maintained by one person who is on leave. The phone number is stored in four formats. An engineer who cannot negotiate those details will write elegant prompts that produce confident answers about the wrong customer.

The escalation rule is the part customers care about most once they see it working. Anything that quotes a price, promises a date, discusses a regulated product or handles a complaint goes to a named human with the context attached. The engineer’s job is to make that handoff feel like a promotion rather than a failure, so the customer’s team trusts the gate instead of routing around it.

Designing infrastructure for people on a call

The design work here starts from a constraint most product designers never face: the user is often on a phone call while using the screen, and cannot read a paragraph. An agent console that explains itself in prose is useless to someone handling a live escalation. The interface has to show state in a glance: which stage the run is in, where it stopped, what it cost, and what the human needs to decide. Everything else is secondary.

The workflow canvas is the opposite problem. It is used in a planning meeting with four people arguing about a process, and it has to be legible from a projector while still precise enough to debug. That means a small vocabulary of node types, a clear distinction between an agent step and a human gate, and a run view that overlays real data on the diagram rather than opening a separate log. The canvas is a shared artefact before it is an editor.

The third surface is the inbox, where WhatsApp, email and voice transcripts converge. Its design problem is trust: an operator needs to know which messages were written by an agent, which were approved by a human, and which are still pending. Getting that wrong in either direction is costly. Mark too much as automated and the team stops reading; mark too little and nobody knows what the system is doing. That is the kind of question the design role owns here, and it is decided with data from real queues rather than from a mood board.

The voice data problem is a language problem

Fourteen Indian languages is a number on a marketing page and a year of work in practice. The hard part is not recording clean audio in a studio. It is that real callers code-mix, change language mid-sentence, use English numbers inside Tamil grammar, and say place names in a way no dictionary records. A model trained on clean read speech will fail on the first real call, and the failure will look like a product bug rather than a data gap.

The contract role covers the pipeline rather than a single recording session: script design with native speakers, recording across genders and ages, transcription with a convention for code-mixed tokens, quality review with a second annotator, and a feedback loop from production failures back into the evaluation set. Consent is part of the pipeline too. Every recording carries a documented consent, and voice data collected for one purpose is not quietly reused for another.

The judgement calls are the interesting part of the job. If a caller says an amount in English inside a Hindi sentence, does the transcript preserve the code-switch or normalise it? If a caller uses a regional word for a scheme that has an official English name, which one goes into the entity field? These decisions become the annotation guide, and the annotation guide becomes the reason two annotators agree. Without it, the dataset is a collection of opinions.

Selling infrastructure to an Indian enterprise

The enterprise sale here is not a demo war. The buyer is usually a head of revenue or operations with a number they have been asked to fix, a procurement team that needs three quotes, and an IT security reviewer who will ask where the data sits before they ask what the product does. The account executive’s job is to run that process without pretending it is shorter than it is.

The qualification question is whether the buyer has a workflow and an owner, not whether they have budget. Plenty of Indian enterprises have budget and no owner, and those deals stall for two quarters while everyone agrees the problem is important. A deal with a named process owner, a defined volume and a compliance path moves in weeks. That distinction is worth more than any lead score, and it is the first thing the role has to get right.

The compliance conversation is where deals are won or lost. A DPDP questionnaire, a sub-processor list, a data processing agreement, a GSTIN invoice and an answer about ap-south-1 residency are table stakes. So is an honest answer about what is not certified. Buyers who have been through an audit can tell the difference between a team that knows its own architecture and a team reading a security page for the first time, and the former closes faster even when the answer is less flattering.

How the hiring process works

Applications arrive through the contact form with the careers intent, and a person reads them. There is no keyword filter and no automated rejection. What helps most is a short note about something you built and the decision you made inside it, plus a link to code, writing or a design file. A CV alone is usually not enough to decide, and a portfolio of screenshots without the reasoning behind them is not either.

The first conversation is thirty minutes with the person who would manage the role. It covers what you have shipped, what you want to learn, and the range we have in mind for the position. That last part happens early on purpose. It is unfair to ask someone to spend a day on an exercise before they know whether the number works, and it is a waste of our time too.

The second step is a working session rather than a trivia interview. For engineering it is a small, bounded problem you can solve with the tools you already use, discussed afterwards rather than graded in secret. For design it is a critique of a real surface with real constraints. For sales it is a discovery call role-play with a difficult buyer. Nobody is asked to do a multi-day unpaid project, and if a take-home is agreed, it is scoped to a few hours and we say so in writing.

The final step is a conversation with someone you would not work with daily, usually a founder, about how you think about trade-offs, failure and customers. Then a decision, usually within a few days of the last conversation. If it is a no, you get a reason that refers to the actual conversation rather than a template. That is slower than a form rejection and it is the standard we hold ourselves to.

What we look for, and what we do not

We look for evidence that you have shipped something into a situation with consequences. That can be a production service, a design system used by a team that complained about it, a dataset someone else depends on, or a sales process you built from nothing. The domain can be learned. The habit of finishing something and living with the result is harder to teach and much easier to spot.

We look for comfort with ambiguity and a low tolerance for hand-waving. A lot of the work here starts with a customer sentence that is half wrong, and the job is to find the real problem without embarrassing anyone. People who need a complete specification before starting tend to struggle; people who write the specification themselves tend to do well. Writing matters in every role, including engineering and sales.

We do not require a particular degree, a particular city, or a brand name on your CV. We do not require you to have worked in AI before, and we are sceptical of anyone who claims to have solved consent or evaluation at scale. What we do require is that you can talk about a failure you caused, what it cost, and what you changed. Candidates who cannot name one usually have not been close enough to production, and this team is close to production every week.

Honest expectations

This is a small team, and small means the work is wider than the title. An engineer will write code, run a customer call and update a runbook in the same week. A designer will ship CSS and argue about empty states with an engineer. An account executive will write the case study and debug an integration question. If you want a narrow lane with a large support function around it, this is the wrong place, and it is better to know that in the first call.

It also means process is thin. There is no elaborate levelling framework, no internal mobility programme, and no promise that a role exists in two years in the shape it exists today. What there is: direct access to the people making decisions, real customers in the first month, and the ability to change how something works by making an argument rather than filing a ticket. For some people that is the whole appeal, and for others it is exhausting.

The practical terms are what they are. Full-time roles are Mumbai hybrid, with remote-friendly arrangements for specialist work, and the voice data engagement is a contract based in India. Some travel to customer sites is normal, particularly in Bengaluru. The team that builds the runtime also carries the pager, because a platform that sells uptime cannot outsource its own incidents. We do not publish perks we have not confirmed, and we would rather answer a specific question than paste a list.

What to send, and what happens next

Send a note through the contact form with the careers intent. Include the role, one thing you built, the decision inside it that you are proudest of, and one thing you would do differently. If you have code, writing or a design file, link it. If you do not, describe the work precisely enough that a stranger could ask a follow-up question about it. That description is itself a work sample.

If there is no open role that fits, send the note anyway and say what you would want to own. The team is small enough that a strong speculative application occasionally creates a role, and honest enough to say when it does not. What will not happen is a polite maybe that turns into six months of silence. If there is no path, you will be told, and you can spend your time somewhere it counts.

One last thing about the framing on this page. The line about building a runtime your auditor will accept is a hiring filter as much as a product statement. It means the work is judged by whether it holds up under scrutiny, not by whether it demos well. If that sounds like the kind of constraint you want, the four roles are real and the process above is how you get in. If it sounds like bureaucracy, that is useful information for both of us.