Position: AI Engineer Agentic AI Developer
Location: Pan India
Total Exp: 6 to 9 Yrs
Role purpose
To take a business problem inside client health, wealth and career operations and deliver the agentic application that solves it. End to end: sit with the team, shape the solution, build it, ship it, instrument it, and stay with it while people come to depend on it. The output of this role is running software in daily use, not a specification. It is a hands-on role, and the expectation is that you are in the codebase every day.
Key responsibilities
Discovery and solution shaping
· Sit in the business team's working sessions, watch the process as it actually runs, and record where the time, the errors and the rework go.
· Turn what you heard into a buildable design within days rather than weeks, and walk the agent owner and the business lead through it before you write code.
· Own the architecture decisions: the agent's tools and boundaries, where state lives, how it authenticates, what it does when a model call fails or a tool returns nonsense.
· Write down the options you rejected and why, because that record is what stops the design being reopened three months later.
· Say plainly what cannot be delivered in the window available, and propose the smaller thing that can.
Build and delivery
· Write the production code for the agent: prompts held under version control, tool definitions, orchestration, retries, fallbacks, and the retrieval or context layer it depends on.
· Build the agent-facing front end so a colleague can see what the agent did, understand why, and correct it without calling you.
· Build the services, APIs and integration layers behind it, and the integration into the systems of record.
· Raise pull requests small enough to be reviewed properly, review other people's, and keep the pipeline green.
· Ship into the client environment with identity, access, secret handling and data residency done correctly the first time.
· Demonstrate working software to the business team on a regular cadence through the build, not at the end of it.
Retrieval, context and the agent's knowledge
· Design the retrieval layer properly: chunking that respects document structure, hybrid keyword and vector search, reranking, and citations the user can check.
· Choose the embedding model and the index, and own the consequences: dimensionality against cost, refresh cadence, and what happens when the index goes stale.
· Know when retrieval is the wrong answer and a query against the system of record, or a deterministic tool, is the right one.
· Engineer the context budget: what goes in the window, what gets summarised, what is remembered between turns, and where prompt caching earns its keep.
Evaluation, instrumentation and operability
· Build the offline golden set alongside the agent, from real cases rather than invented ones, and gate every change on it in the pipeline.
· Build LLM-as-judge scoring where human review will not scale, calibrate the rubric against human scores, and re-check that agreement rather than trusting the judge.
· Measure retrieval separately from generation, so a bad answer is traced to the chunk it missed rather than blamed on the model.
· Instrument every agent run with distributed tracing: inputs, tool calls, retrieved context, decisions, latency, token cost and outcome.
· Watch live traces in the days after a release, find the failure modes, and record each one with the guardrail you added against it.
· Run shadow or canary releases for anything that touches a live process, and set the alerting that tells us an agent has drifted before the business team does.
· Report quality against the acceptance criteria the agent owner set, honestly, including the misses.
Guardrails, cost and model choice
· Build the input and output guardrails: PII handling, prompt injection resistance, grounding and citation checks, and a clean escalation path when the agent should refuse.
· Choose models on measured evidence, route between them where a smaller one suffices, and report cost per resolved task rather than cost per token.
· Know the difference between a prompt problem, a retrieval problem, a tooling problem and a model problem, and fix the right one.
Data and integration
· Model the business domain in the design rather than bending the business to a convenient schema.
· Profile the data before you trust it, and tell the agent owner when the process depends on a field that is half empty.
· Test integrations against production-shaped data, including the malformed records nobody mentioned in the workshop.
Handover and reuse
· Document the build so another engineer can take it on without you, and keep that document current.
· Turn what you built twice into something the team can reuse, and tell the team it exists.
· Raise risk early, in plain terms, to the technology lead.
コグニザントについて
コグニザント（NASDAQ: CTSH）は、AI Builderおよびテクノロジーサービスプロバイダーとして、お客様にフルスタックのAIソリューションを構築することで、AI投資と企業価値を結ぶ架け橋となっています。業界、ビジネスプロセス、エンジニアリングに関する当社の深い専門知識を活かし、組織固有のビジネス環境をテクノロジー・システムに組み込みます。これにより、人間の可能性を最大限に引き出し、確かな成果を実現するとともに、急速に変化する世界においてグローバル企業が常に一歩先を行くための支援を行っています。 詳細については、cognizant.ai をご覧ください。
雇用に関する追加情報
本募集に記載されている報酬情報は、掲載日時点で正確なものです。Cognizantは、適用される法令に従い、いつでも本情報を変更する権利を留保します。
応募者は、対面またはビデオ会議による面接への参加を求められる場合があります。また、各面接の際に、現在有効な州政府または政府発行の身分証明書の提示を求められる場合があります。
Cognizantは機会均等雇用主です。応募および選考において、人種、肌の色、性別、宗教、信条、性的指向、性自認、国籍、障がい、遺伝情報、妊娠、退役軍人の地位、その他連邦法・州法・地方自治体の法律により保護されるいかなる特性に基づく差別も行いません。
