About C5i

Founded in 2000, C5i enables organisations to make the most effective strategic and tactical moves relating to their customers, markets and competition, at the pace the digital business world demands.

We build AI products: Agent5i, our enterprise agentic AI system; Compete, digital shelf analytics for brands selling through retail; Incivus, creative effectiveness for marketing teams; and Synthetic Audiences, virtual respondents for research teams who need an answer faster than a panel can return one. Each has its own users, roadmap, release cycle and stack today, running across Azure, AWS and GCP.

What We Seek

You sit between what the products need to do and which method will actually do it.

This is an internal product seat: no customer calendar, no pre-sales. The work is generative and agentic by default. Agent decomposition, tool and function contracts, orchestration, context assembly, retrieval design, guardrails and evaluation. Fine-tuning and domain-specific small models where they beat prompting on cost or accuracy. Knowing which to reach for, and recognising when none of them is the answer, is most of the job.

Every capability as a feature resolves to one of three things: a pattern the products already support, something worth building once and using across all four, or a no. You make that call before engineering commits to it. Getting it wrong in the generous direction is how a product ends up with four implementations of the same idea.

This is a hands-on seat. You will specify an architecture and prototype it yourself in the same week. A design that reads well and cannot be built is a failure, and so is a method that works in a notebook and falls over at ten thousand users.

The domain moves with the product: retail and consumer goods in Compete, marketing in Incivus, research in Synthetic Audiences, and whatever Agent5i lands in next. Depth in method transfers, depth in a single industry does not, and we are hiring for the former. Your designs become constraints for the Full Stack Architect and the Cloud and Data Architect, so involving both early is expected rather than optional.

Yes, that means reading Papers with Code, working out which of it holds, and turning the one paper in twenty that does into a feature the products can ship. That is Applied AI in this seat. Wiring up tool calls is not.

How We Work

Flat. Three things decide whether you succeed here, and we weight them above any line on your CV.

Proactivity. Nobody hands you a scoped problem. Find where a product is losing to its own method,



size it, decide whether it is worth solving now, then design it. The same applies to research: much of what is published is not production-ready, and saying so in week one rather than after three months of build is part of what this seat is for.

Adaptability. The domain changes with the product and the methods change faster. Model providers change, agent frameworks are superseded, roadmaps move. Treat the churn as normal rather than as a planning failure.

Accountability. You own the outcome from design to production, not the design. There is no handover at specification. You stay with it through build and evaluation, and if the estimate was wrong it was your estimate. Delegation to the engineering team is not available.

What You Will Own

- Method selection: whether prompting, retrieval, fine-tuning, a domain-specific small model or none of them is right for a given capability, across all four products.
- Core, shared or no: whether a capability belongs in one product, is worth building once for all four, or should not be built at all.
- Agentic system design: agent decomposition, tool and function contracts, orchestration, context assembly, guardrails and human-in-the-loop points.
- Retrieval and domain model strategy: hybrid retrieval, chunking and reranking, and fine-tuning or domain-specific small models where they beat prompting on cost or accuracy.
- Evaluation strategy: success criteria agreed with product before build, including golden sets, acceptance thresholds and regression suites.
- Feasibility and estimation: what a roadmap item costs to build and what it costs to serve, established before it is committed.
- Prototypes and method assessment: fast calls on whether an approach is worth pursuing, and on which published research is production-ready.
- Continuity through build, with the Full Stack Architect and Cloud and Data Architect involved early rather than at specification handover.

Must Have

- 8 to 12 years in applied machine learning with production ownership. Bachelor’s or master’s in Computer Science, Engineering or a related field. Why:



the method choice and the cost of that choice sit in the same seat here.
- Four or more AI products or platforms taken from design to production and scaled to a live user base between 1,000 and 100,000. Why: designing for scale is a different problem to designing a pilot. Concurrency, cost per query, evaluation drift and support load only surface past a few hundred users. Four is deliberate: it takes several to separate judgement from one lucky architecture.
- Shipped generative AI to production users with accountability for the outcome: retrieval-augmented generation, agentic workflows, tool and function calling, structured output. Why: internal pilots and demos never meet the failure modes that decide whether a feature survives its first month.
- Current working knowledge of agentic patterns, retrieval architectures, fine-tuning approaches and model evaluation. Why: this field resets roughly every two quarters, and knowledge that is eighteen months old picks the wrong method.
- Evaluation design: golden sets, acceptance thresholds, regression suites and human review loops. Why: without criteria agreed before build, "not good enough" arrives at release with no way to settle it.
- Able to reach working depth in an unfamiliar business domain fast enough to design for it. Why: the domain moves with the product, and a retrieval design that ignores how the domain actually works fails quietly rather than loudly.
- Has written code recently and can still do so. Why: you prototype your own ideas, and estimates from people who no longer build are consistently wrong.
- Judgement to decline a method that would work once and not generalise. Why: four implementations of the same idea cost more to keep than one that was harder to design, and this seat is the only place that gets caught before build.

Good to Have

- Domain-specific language model or retrieval system design.
- Cost modeling for inference at scale: token economics, unit cost per query, caching and routing strategy.
- Evaluation harnesses or benchmark suites built for other teams to reuse.
- Responsible AI governance and model risk practice.
- More than one product domain: consumer goods, retail, marketing, pharma or supply chain.
- Published work, patents or conference contribution.

On the Experience Band The band is deliberate. Above it we consistently meet people who have optimised for depth in a settled setting, or who have moved far enough from implementation that design has come to mean specification. Neither works here.

📌 AI Solutions Architect (Bengaluru)
🏢 C5i
📍 Bengaluru