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.
关于高知特 (Cognizant)
高知特(Cognizant)（纳斯达克代码：CTSH）作为一家AI Builder和相关技术服务提供商，致力于通过打造全栈AI解决方案，帮助企业将人工智能投资转化为实际价值。公司凭借深厚的行业经验、流程优化和工程技术专长，将企业独特的业务场景融入科技系统，赋能组织释放人才潜能，推动切实成果，并帮助全球企业在瞬息万变的环境中保持领先。如需了解更多详情，敬请访问 cognizant.ai 或关注@cognizant。
补充雇佣信息
薪酬信息截至本职位发布之日为准。Cognizant 保留在适用法律允许的范围内随时修改该信息的权利。
申请人可能需要通过现场面试或视频会议的方式参加面试。此外，候选人在每次面试时可能需要出示其当前所在州或政府签发的有效身份证件。
Cognizant 是一家提供平等就业机会的雇主。在招聘过程中，您的申请和候选资格不会因种族、肤色、性别、宗教、信仰、性取向、性别认同、国籍、残疾、遗传信息、怀孕、退伍军人身份或任何其他受联邦、州或地方法律保护的特征而受到影响。
