यह किताब जो roles train करती है
Market titles को define करने से तेज़ invent कर रहा है। इनमें से ज़्यादातर titles एक ही discipline के अलग-अलग depths हैं: वही discipline जो यह किताब सिखाती है। यहाँ map है, और हर role की तरफ यह किताब आपको ठीक कहाँ तक ले जाती है।
यहाँ हम नए agentic AI era के roles define करते हैं: वे jobs जो इसलिए exist करती हैं क्योंकि companies अब AI Workers को manufacture, run और govern करती हैं। Entries को इस हिसाब से sort किया गया है कि work असल में कैसे cluster होता है, और हर entry के साथ verdict एक honest scope line है: यह किताब आपको उस role तक कहाँ तक ले जाती है, और कहाँ certification tracks आगे संभालते हैं। Verdicts names से ज़्यादा important हैं। जहाँ किताब रुकती है, वह साफ़ कहती है।
हर कोई same Foundations से शुरू करता है, यानी browser skills जिनकी ज़रूरत किसी भी agent work से पहले हर reader को होती है। इसी floor पर general agent use के दो modes बैठे हैं। Mode 1 का मतलब है general agent से अपना काम तेज़ करना, यह हर reader की proficiency है, job title नहीं। Mode 2 का मतलब है AI Workers manufacture करना जो आपके लिए काम करते हैं, और वहीं job titles आते हैं। Map Foundations floor और Mode 1 Practitioner से शुरू होता है, फिर Mode 2 roles की तरफ जाता है, जो इसका लगभग पूरा हिस्सा हैं।
Vocabulary में नए हैं (Digital FTE, SKILL.md, Agent Factory)? पहले Thesis और Glossary से शुरू करें; यह page मानता है कि आप इन्हें जानते हैं.
पूरा map एक नज़र में: core pipeline, उसे extend और support करने वाली चीज़ें, किताब कहाँ रुकती है, और उसके नीचे की baseline.
वह baseline जहाँ से हर कोई शुरू करता है
Foundations: floor, किसी भी mode से पहले। हर reader same तरह से शुरू करता है, browser tab में, Foundations पर: prompting कैसे करें, agentic work की दो document languages, वह code कैसे commission करें जिसे आप खुद कभी नहीं लिखते, skills और connectors, और AI era में कैसे सोचें। कोई mode नहीं, कोई role नहीं, install करने को कुछ नहीं। यही वह floor है जिस पर पूरा map खड़ा है। जहाँ हर कोई शुरू करता है, कोई title नहीं।
Mode 1 Practitioner: title नहीं, proficiency है। इसी floor पर आप general agent से अपना काम तेज़ करते हैं: reason करना, लिखना, code करना, analyze करना, plan करना, outcome ship करना और session close करना। यही Mode 1 है, और किताब इसे सबके लिए train करती है: engineers के लिए Claude Code या OpenCode के through, domain experts के लिए Claude Cowork या OpenWork के through, Seven Principles of General Agent Problem Solving के under। यह पहला mode है जो हर reader नीचे दिए Mode 2 roles से पहले run करता है, और यह आपको आपके existing job में sharper बनाता है, नया title नहीं देता। पहला mode जो हर कोई run करता है, कोई title नहीं।
Generalist core
ये core roles एक single pipeline की तरह चलते हैं, intent से production तक: Outcome Architect (क्या) → Digital FTE Builder (build) → AI-Native Company Architect (system) → Cloud AI Engineer (run)। इसे अपनी company के अंदर चलाएँ तो ये चार roles हैं; इसे client की company के अंदर चलाएँ, end to end एक embedded, vendor-neutral engineer carry करे, तो यह Forward Deployed Engineer है। Map पर बाकी सब कुछ इसी line को support, extend या bound करता है।
चार roles आपकी अपनी company के अंदर line run करते हैं; एक embedded engineer वही line client की company के अंदर carry करता है.
Outcome Architect: intent own करता है, execution नहीं। Agent era में work तीन हिस्सों में split होता है: intent, execution, verification। Worker execution own करता है; यह role intent own करता है। यह तय करता है कि Worker को क्या achieve करना चाहिए, spec लिखता है जो उसे pin down करती है, "correct" का मतलब set करता है, और prioritize करता है कि कौन से Workers पहले build हों। Builder कैसे का जवाब देता है, उससे पहले यह human क्या और क्यों का जवाब देता है। जहाँ Strategist track client-facing discovery और ROI own करता है, Outcome Architect internal Worker roadmap और उसके पीछे की specs own करता है। किताब इसे सीधे train करती है: spec-driven development अपने core में वही discipline है जिसमें आप intent ऐसा लिखते हैं कि Worker को उसके against hold किया जा सके। इसे train करती है: वही discipline जिस पर पूरा method टिका है.
Digital FTE Builder: unit product, end to end built। Market इसे AI Engineer कहता है, यानी ऐसा catch-all title जो AI components से applications build करने और AI coding agents drive करने वाले व्यक्ति के लिए use होता है। इस किताब का नाम sharper है, क्योंकि आप जो build करते हैं वह sharper है: Digital FTE, वह unit जिससे पूरी company assemble होती है। यह किताब का primary graduate है। यह full spine train करती है: spec-driven development, SKILL.md authoring, agent architecture, tool और MCP interfaces, evaluation और human oversight, deployment इतना कि आप ship कर सकें, और deeper production depth Cloud AI Engineer के लिए छोड़ती है। इसे end to end train करती है.
AI-Native Company Architect: company design करता है, single Worker नहीं। पूरी enterprise: Two-Layer Model, management layer, workforce, उनके बीच events carry करने वाला nervous system, और वह system of record जिसके against सब कुछ run होता है। Agent Factory वह process है जिसे यह architect practice करता है; AI-Native Company वह product है जो वह ship करता है। किताब इसका canonical source है। पाँच-quarter Certified Agentic AI Architect program इसकी credential है। पूरी तरह train; Architect track से certified.
Cloud AI Engineer: production में AI Worker और AI-Native Company run करने वाला person। Digital FTE build करना काम का आधा हिस्सा है; उसे reliably run करना दूसरा आधा है। उसी तरह पूरी AI-Native Company को run करना भी इसका हिस्सा है। जहाँ AI-Native Company Architect enterprise design करता है, यह role उसे operate करता है: Workers, management layer और nervous system को real cloud infrastructure पर deploy और scale करना, ship करने के लिए Azure Container Apps, durable execution के लिए Inngest, scale के लिए Dapr और Kubernetes। यही वह जगह है जहाँ system prototype से आगे बढ़कर ऐसी company बनता है जिस पर organization depend कर सकती है। इसे end to end train करती है.
वे दो roles जिन्हें लगभग कोई और train नहीं करता
Subject Matter Expert as Skill Author: वह role जिसे market ने अभी name नहीं दिया। Accountant, lawyer या supply-chain expert जो judgment को SKILL.md में encode करता है और Digital FTE का knowledge engine बनता है। Market की ज़्यादातर lists इस role को miss कर देती हैं क्योंकि वे अभी भी AI work को engineering-only समझती हैं। यह किताब domain judgment को ऐसी चीज़ मानती है जिसे author, test और deploy किया जा सकता है। यह उन दो roles में से एक है जिन्हें लगभग कोई और train नहीं करता। इसे पूरी तरह train करती है: judgment अंदर, working agent बाहर.
Forward Deployed Engineer (FDE): वह vendor-neutral version जो market को नहीं मिलता
FDE असल में क्या करता है। ज़्यादातर software engineers headquarters में product build करते हैं और उस customer से कभी नहीं मिलते जो उसे use करता है। FDE इसका उल्टा करता है। वे customer के real workplace में जाते हैं, काम कर रहे लोगों के साथ बैठते हैं, उन लोगों की real problems समझते हैं, और वहीं, on-site, अपनी company के platform से solutions build करते हैं। Demo नहीं। Slide deck नहीं। ऐसा working software जो customer के real environment में run करता है।
इसे ऐसे समझें: एक doctor दूसरे शहर से आपकी chart पढ़ता है, और दूसरा doctor room में बैठकर आपको examine करता है और उसी समय treatment शुरू करता है। FDE दूसरा doctor है।
Palantir, जो governments और large enterprises के लिए software build करने वाली major data analytics company है, ने early 2010s में यह role create किया था और शुरुआत में इन्हें "Deltas" कहा।1 लगभग 2016 तक Palantir में regular software engineers से ज़्यादा FDEs थे, क्योंकि उसके customers, government agencies और large traditional enterprises, को on-site ऐसे person की ज़रूरत थी जो startup mentality से internal bureaucracy cut through कर सके। Palantir difference सबसे साफ़ explain करता है: regular developer one capability, many customers पर focus करता है (एक feature build करें, सबको ship करें), जबकि FDE one customer, many capabilities पर focus करता है (एक client के साथ embed हों, जो भी ज़रूरत हो solve करें)। Job description scope capture करती है: यह startup CTO जैसा दिखता है। High-stakes projects पर आप start से finish तक सब own करते हैं।
यह Solutions Architect या Sales Engineer जैसा नहीं है। Solutions Architect advise करता है: demos run करता है, whiteboards पर solutions design करता है और sample data से proof-of-concept prototypes build करता है ताकि prospect sign करे। Deal close होने के बाद उसका involvement आम तौर पर कम हो जाता है। FDE वहीं से उठाता है जहाँ Solutions Architect छोड़ता है। वे customer की infrastructure पर real data के साथ production code लिखते हैं, और तब तक रहते हैं जब तक customer को real value न मिले। Simple test: अगर role customer-specific work को production में सच में function करवाने के लिए accountable है, तो वह FDE के करीब है। अगर वह product को prove या explain करने के लिए accountable है, तो वह solutions architect के करीब है।
Real example: OpenAI की deployment team John Deere के साथ embed हुई, जो लगभग 190 साल पुरानी farming company है, ताकि planting-season problem ground पर solve की जा सके। हर farmer के अपने past usage से काम लेकर उन्होंने AI-powered recommendations build करने में मदद की कि See & Spray, John Deere के targeted weed-control system, से farmer को कितना कम chemical चाहिए होगा। John Deere ने इस work को chemical use में लगभग 70% कमी और customer engagement में sixfold lift का credit दिया।2 Deadline product roadmap नहीं, planting calendar था। यही FDE job एक line में है: real production software, customer की दुनिया में built, और तब shipped जब customer को सच में ज़रूरत हो।
FDE वह जगह है जहाँ code, product और customer मिलते हैं: software engineer की build capability, platform engineer की product instincts, और solutions architect की customer read, एक ऐसे person में जो customer की दुनिया में build करता है, headquarters में नहीं.
क्यों अब हर AI company FDEs चाहती है। 2025 के पहले तीन quarters में FDE job postings 800% से ज़्यादा बढ़ीं।3 Salesforce ने अपनी Agentforce platform support करने के लिए dedicated FDE team बनाई।4 OpenAI ने "Deployment Company" create की, एक majority-owned subsidiary जिसे investor consortium से लगभग $4 billion backing मिली, और जो largely enterprises को FDEs staff करने के आसपास बनी।5 इसकी वजह simple है: 2025 MIT Media Lab study (Project NANDA) ने पाया कि custom enterprise AI pilots में से लगभग 95% measurable return नहीं दिखाते।6 इसलिए नहीं कि AI काम नहीं करता, बल्कि इसलिए कि उसे company के messy, real-world systems में fit करना बहुत hard है। FDEs इसी gap को close करने के लिए exist करते हैं। वे reason हैं कि Palantir late 2024 तक $136 billion market cap पार कर गया, Lockheed Martin से आगे निकल गया,7 और अब हर AI company model replicate करना चाहती है।
Vendor lock-in problem। Catch यह है। Palantir का हर FDE Palantir की platform पर build करता है। OpenAI का हर FDE OpenAI के models पर build करता है। Salesforce का हर FDE Salesforce के tools पर build करता है। Engineer client की company में गहराई तक जाता है, उस एक vendor का product हर जगह wire करता है, और चला जाता है। बाद में switch करना painful और expensive होता है, जैसे ऐसा plumber जो सिर्फ़ एक brand की pipes install करता है: plumbing काम करती है, लेकिन आप walls तोड़े बिना दूसरा plumber hire नहीं कर सकते। जैसा Andrew Ng ने The Batch में note किया,8 clients को ऐसे FDEs मिलना मुश्किल होता है जो single vendor से tied न हों, क्योंकि vendor के लिए role का point ही client को lock in करना है।
यह किताब वही FDE train करती है जिसे market माँगता रहता है लेकिन ढूँढ़ नहीं पाता। यहाँ का method किसी vendor से bound नहीं है। इस किताब का graduate full pipeline carry करता है (intent spec करें, Worker build करें, system design करें, production में run करें) client organization के अंदर, बिना उन्हें किसी single platform में lock किए। Next quarter बेहतर model आए, या next year cheaper runtime ship हो, तो आप switch करते हैं। Client choice की freedom रखता है, और आप वह discipline रखते हैं जो किसी भी stack पर काम करता है। एक honest tradeoff भी नाम लेना चाहिए: vendor का FDE heavily subsidized होता है, कभी-कभी free, क्योंकि vendor lock-in से वापस earn करता है; vendor-neutral FDE को client या independent firm pay करती है। यही feature है, bug नहीं: client अभी optionality खरीद रहा है, बाद में switching costs नहीं दे रहा।
यह दूसरा role है जिसे लगभग कोई और train नहीं करता। और claim को exact रखने के लिए: किताब vendor-neutral FDE का technical core train करती है, वही आधा हिस्सा जो market को नहीं मिलता। दूसरा आधा, client discovery, prioritization, ROI framing, और unrealistic ask पर push back करने की discipline, Certified Agentic AI Business Strategist track का है। Technical core train करती है; consulting layer Strategist track में रहती है.
Supporting roles
हर pipeline को ऐसे लोग चाहिए जो work check करें, rules set करें और responsibility लें। ये तीन roles वही करते हैं।
Evals Engineer: वह person जो AI Workers को live जाने से पहले crash-test करता है। आप बिना crash-test के car ship नहीं करेंगे। आप बिना clinical trials के medicine release नहीं करेंगे। एक AI Worker जो real people और real money को affect करने वाले decisions लेता है, उसे भी वही discipline चाहिए। Evals Engineer ये tests design करता है: क्या Worker सही answer देता है? जब उसे ऐसा कुछ मिलता है जो उसने पहले कभी नहीं देखा, तो क्या वह gracefully fail करता है? क्या वह दिए गए boundaries के अंदर रहता है? यह अंत में bolt-on किया गया afterthought नहीं है। यह हर chapter में built in है। Core curriculum, add-on नहीं.
AI Governance Officer: तय करता है कि AI क्या कर सकता है। Company में हर employee की limits होती हैं। Junior accountant $500 तक expenses approve कर सकता है, उससे ऊपर manager signature चाहिए। Bank teller deposit process कर सकता है, loan approve नहीं कर सकता। AI Workers को भी वही structure चाहिए। Governance Officer company level पर ये rules लिखता है: AI अपने आप क्या decide कर सकता है, क्या human approval के लिए जाना चाहिए, और AI को क्या कभी touch नहीं करना चाहिए। वह company की regulations से mapping भी handle करता है: bank में fair lending rules, hospital में patient privacy, Europe में data residency laws। AI-Native Company Architect वह system build करता है जो ये rules enforce करता है; Governance Officer decide करता है कि rules में क्या लिखा होना चाहिए। किताब यह framework discipline सीधे train करती है; आपकी industry की specific regulations वह inputs हैं जो आप लाते हैं। Governance framework train करती है; आपकी jurisdiction के rules आप supply करते हैं.
Digital FTE Supervisor: वह human जिसका नाम line पर है। जब AI Worker claim process करता है, contract draft करता है या transaction flag करता है, तो किसी को accountable होना पड़ता है। वही Supervisor है। वे human-in-the-loop हैं: reviewer जो work check करता है, manager जो output approve करता है, वह नाम जिसकी तरफ audit trail इशारा करती है जब कुछ गलत होता है। यह Worker build करने वाला person नहीं है। यह वह person है जो उसे day to day run करता है, जैसे shift manager team run करता है। इसे train करती है.
जहाँ किताब जान-बूझकर रुकती है
LLMOps Engineer: model तक, model itself नहीं। Production में agents run करना Cloud AI Engineer का job है, और किताब इसे train करती है। किताब fine-tuning hands-on भी train करती है, लेकिन last resort के रूप में, default नहीं। Fine-tune आपके system को एक model snapshot से bind करता है और उस optionality की cost लगाता है जिसे पूरा method protect करता है, इसलिए आप इसे तभी use करते हैं जब prompting, context, tools और retrieval सच में कम पड़ जाएँ। Hard stop model itself build करना है: foundation model को scratch से pre-train करना scope से बाहर रहता है, क्योंकि वह capability commoditize हो रही है। Fine-tuning और model के आसपास ops train करती है, foundation models build करना नहीं.
Harness Engineer: वह runtime जिसे आप use करते हैं, वह नहीं जिसे आप build करते हैं। Harness agent runtime है: OpenAI Agents SDK, Claude के managed agents और ऐसी चीज़ें, जो agent loop run करती हैं, state manage करती हैं और tool calls execute करती हैं। किताब आपको इन्हें fluently use करना और इनके बीच portable रहना train करती है, क्योंकि आपकी discipline किसी भी winning runtime से ज़्यादा long-lived है। Runtime itself build करना job नहीं है। किसी भी runtime का use करने वाले operator को train करती है, उसे build करने वाले engineer को नहीं.
AI Data Engineer: agent-facing data layer। System-of-record work agent-facing data layer को touch करता है: Postgres, pgvector और MCP वह spine हैं जिससे agent read करता है। Classic pipeline और warehouse engineering adjacent हैं, central नहीं। Agent-facing data layer train करती है, general data engineering नहीं.
Pattern ही signal है। Agent era work को कई roles में फैलाता है, एक में नहीं: Workers build करना, उन्हें run और govern करना, उन्हें judgment सिखाना। Map point है: देखें कि आप अभी कहाँ खड़े हैं, और यह किताब आपको वहाँ से कितना आगे ले जाती है।