Bengaluru, India
Most of the team works here
PaiteqHD-101(A) WeWork Salarpuria Symbiosis
Bengaluru, Karnataka 560077
India
The first reply comes from the AI engineer who would lead the work. Same day on most inbounds, Bengaluru business hours.
The discovery call goes faster when you bring these three things. None of them are blockers — we've run audits off a Slack message describing the workload. The more concrete the input, the sharper the audit deliverable.
A workload with a problem statement, current cost (people-hours, ticket volume, doc throughput — whatever the metric is), and what success would look like. We'd rather audit one workload deeply than ten shallowly.
A read-only data tap to start — a CSV export, a sample of tickets / invoices / calls, or a sandbox API key. No write access until the pilot phase, no production data until NDA + DPA where applicable.
We run the audit on our side — you don't prep slides. The discovery call is a conversation: what you do, what's broken, what you've tried, where the AI work has to land in your existing systems.
If you want a written reply on a specific question, email beats every other channel — it routes straight to engineering. Phone and WhatsApp are best for time-sensitive coordination once we're already engaged.
Honest framing: Bengaluru is where the team works on-site. Dallas is a registered US mailing address for clients who need a US point of contact — there is no team on the ground there. We are a remote-first studio.
Most of the team works here
PaiteqMail forwarding · no team on-site
PaiteqA 90-second form. An engineer reads it and replies — usually within a few hours during Bengaluru business hours, same business day otherwise.
Eight things every inbound asks before signing the NDA. If yours isn't covered, the inquiry form is the fastest way to ask.
An AI engineer — usually a senior who would actually be on your pilot. Inbounds land directly in an engineer's inbox, not a sales queue. The reply digs into what you sent — what systems it touches, where the judgment lives, what counts as success — and asks the questions that move the scope forward. Some inbounds need a short reply; complex ones get a long one. Most get a same-day response; long-form RFPs may take a day extra because the read takes longer.
If the work isn't a fit, we'll say so on the reply and route you elsewhere if we can. The trade-off for talking to engineering early: harder technical questions earlier rather than smoother demo-deck questions.
Yes. We counter-sign your NDA before the discovery call, or send ours if you don't have one. For regulated workloads (healthcare, finance, legal), we also sign a DPA before any data touches our infrastructure. Until the pilot kicks off, we recommend the audit phase run on anonymised samples even after the NDA — keeps the surface area small while we're still scoping.
You do. The audit memo, the eval set, the prompts, the workflow code, the deployment scripts, the ops runbook — all of it transfers to you. We retain the right to reuse operator patterns ("how to ship a tier-1 deflection agent", "how to structure a RAG eval") but not your prompts, your data, or your code. Standard work-for-hire terms in the pilot + continuous contracts.
You keep the deliverable — the workload map, the model-cost projection, the 90-day roadmap, the risk-tier ladder — and you walk away. That's the walk-away clause baked into every engagement. We'd rather lose a pilot we shouldn't have sold than ship something that won't move the metric.
The honest version of this is: about 1 in 5 audits we run end up recommending no AI work, or recommending you defer for 6 months until a prerequisite (data quality, eval ground truth, internal champion) is in place. That's the whole point of separating the $3K audit phase from any pilot money.
Typical sequence: discovery call this week → audit deliverable in 1–2 weeks → pilot kickoff within 1–2 weeks of audit sign-off. So 3–5 weeks from "first call" to "engineers writing pilot code".
If you're under a real deadline (board demo, regulator timeline, contract milestone), tell us in the form. We can compress the audit phase or run NDA / DPA paperwork in parallel. We won't compress the eval set work — that's load-bearing for the pilot ship gate.
HIPAA — yes for HIPAA-aware patterns. We ship Claude on AWS Bedrock with a BAA and PrivateLink VPC, audit-logged, with field-level masking on PHI before any model call.
GDPR — yes for GDPR-aware DPAs and EU-region residency on hosted models (Anthropic EU, OpenAI EU data residency, Azure West Europe). Subject-access-request workflow documented in the ops runbook.
SOC 2 — partial. We follow SOC-2-ready practices (audit logs, least-privilege IAM, key rotation, encryption at rest and in transit) but we are not ourselves SOC 2 Type II certified as a vendor. If your procurement requires a SOC 2 Type II report from the agency itself, flag that on the call and we'll route accordingly.
Engineers. The discovery call is run by someone who would actually be on your pilot — typically a senior AI engineer plus a product / PM lead who has shipped similar shapes. We don't have a separate sales team.
The trade-off: we ask harder technical questions earlier ("what's the schema of that ticket data?", "what's your p99 latency budget?", "where does the human-in-the-loop sit today?") rather than smoother demo-deck questions. If you're earlier in the buying cycle and want a polished overview before a technical conversation, the per-pillar service pages and case-studies index cover that better than a call would.
Per workload, not per vendor. Long-context reasoning lands on Claude Sonnet 4.6 most of the time. Realtime voice agents go to OpenAI Realtime API for sub-400ms first-token latency. Cost-sensitive batch workloads run on open-weight models (Llama 4, Mistral) self-hosted on vLLM where the volume justifies it. Regulated workloads on Bedrock with BAA.
The model pick is part of the audit deliverable, with the reasoning shown. We'll tell you honestly when not to use a model — see the per-pillar pages for the per-vendor positioning across LLM, RAG, agents, and chatbots.
Twelve service pillars, with engagement shapes, eval methodology, and stack picks per workload.