Private corporate batches, live online cohorts and 1-on-1 mentoring in building production software on the OpenAI API — prompting, structured outputs, tool calling, retrieval, evaluation, cost control and safety — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches the OpenAI platform as production engineering rather than prompt tips: structured outputs with strict JSON Schema so responses parse without defensive code, tool calling and the loop that runs around it, retrieval pipelines where retrieval quality is measured separately from generation quality, and evaluation harnesses that run in CI and block a regression. Sessions give equal weight to the operational side — token accounting per feature, prompt caching and batching, streaming and timeout behaviour, rate limits and backoff, model deprecation and migration, and the architectural mitigations for prompt injection — because those are the things that decide whether an LLM feature survives its first month of real traffic.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For OpenAI that means a trainer who has run it in production — building production software on the OpenAI API — prompting, structured outputs, tool calling, retrieval, evaluation, cost control and safety — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private OpenAI batchOpenAI is an AI research company whose models are consumed by engineering teams through an HTTP API. For a developer, the platform is a small set of endpoints with very different characteristics: a text generation interface that takes a list of messages and returns a completion, an embeddings endpoint that turns text into vectors for search, audio endpoints for transcription and speech, an image endpoint, a moderation endpoint, a batch interface for high-volume asynchronous work, a fine-tuning interface, and a realtime interface for low-latency speech-to-speech interaction.
What separates a working feature from a demo sits almost entirely outside the model call. Structured outputs constrain a response to a JSON Schema so downstream code can parse it without defensive string handling. Tool calling lets the model request that your function be executed and then continue with the result, which is how a language model gains access to a database, a search index or an internal API. Retrieval augmentation supplies relevant context at request time so answers are grounded in your own material rather than in whatever the model absorbed during training. Reasoning-oriented models spend additional tokens thinking before answering, which changes both quality and cost. Prompt caching, batching and streaming change the economics and the perceived latency.
Operating on the OpenAI platform is also an ordinary engineering problem. There are rate limits expressed in requests and tokens per minute, 429 responses that need backoff, per-project API keys and spend limits, usage data that has to be attributed to features, model versions that get deprecated on a schedule, and a moderation and abuse surface that has to be handled before launch rather than after. Azure OpenAI Service exposes broadly the same models with different deployment, networking and data-residency properties, which is why many regulated organisations run there instead.
Almost every engineering organisation now has LLM features in flight, and the bottleneck has moved. Capable models are a commodity behind an API; the differentiating work is retrieval quality, output reliability, evaluation, latency and cost — all of which are ordinary software engineering applied to an unfamiliar component that is non-deterministic and billed per token.
The failure pattern is consistent. A prototype impresses in a week, then stalls for months because nobody can answer three questions: is it actually better than the previous version, what does it cost at real volume, and what happens when it is confidently wrong. Teams that build an evaluation harness, instrument token spend per feature, and design for the wrong answer get to production. Teams that iterate on prompts by feel do not.
There is a security dimension too, and it is genuinely new. Any system that puts untrusted content into a model's context and gives that model tools is exposed to prompt injection, and no amount of prompt wording fixes it — the mitigations are architectural. Combine that with data-residency obligations, retention policies, consent for sending customer data to a third-party API, and emerging regulatory expectations around documentation and risk assessment, and the result is that shipping an LLM feature responsibly requires engineering discipline that most teams are building for the first time.
A working map of what the API actually offers before writing anything. The generation interface and its message roles, the other endpoints and when each applies, the difference between general and reasoning-oriented model families, and the parameters that materially change behaviour — plus the account mechanics of keys, projects and spend limits.
Topics: API surface: text generation, embeddings, audio, images, moderation, batch, fine-tuning, realtime · Message roles and the instruction hierarchy · Model families: fast and cheap, general purpose, reasoning-oriented · Reasoning effort and reasoning tokens as a cost and quality dial · Parameters that matter: temperature, top_p, max output tokens, stop, seed, logprobs · Tokens, tokenisation and context windows in practice · Streaming responses and when not to stream · API keys, projects, spend limits and usage attribution · Model versions, snapshots, deprecation and migration · Azure OpenAI Service: deployments, versioning, residency and networking
Prompting treated as an engineering artefact rather than a craft. Instruction structure that survives varied input, examples and when they help, decomposition instead of one enormous prompt, deciding what belongs in context at all, and versioning prompts alongside the tests that prove a change was an improvement.
Topics: Instruction structure: role, task, constraints, output contract · Developer and system instructions versus user content · Few-shot examples: when they help and when they anchor badly · Decomposition and chaining instead of one large prompt · Context engineering: what to include, what to summarise, what to leave out · Delimiters and separating instructions from untrusted content · Prompting reasoning models differently from general models · Handling refusals, truncation and empty responses · Prompt versioning, storage and review in source control · Reproducibility: seeds, snapshots and their real limits
Making a probabilistic component safe to call from deterministic code. Constraining responses to a JSON Schema, designing schemas the model can satisfy, validating on the way out anyway, and handling every failure an HTTP call to a language model can produce — timeouts, truncation, refusals, rate limits and malformed output.
Topics: Schema-constrained structured output and strict mode · Designing schemas a model can reliably satisfy · Enums, unions and optionality — what to avoid · Validating and coercing responses on the client side · Truncation, max output tokens and detecting incomplete responses · Refusals and safe-completion behaviour as a first-class case · Timeouts, retries, idempotency and backoff on 429 and 5xx · Rate limit headers and client-side throttling · SDK usage in Python and TypeScript, and calling the raw HTTP API · Logging requests and responses without logging sensitive data
Giving a model the ability to act. Declaring tools with JSON Schema, the loop your code runs when a tool call comes back, validating arguments before execution, returning errors the model can recover from, and the point at which a multi-step agent becomes less reliable than an explicit workflow.
Topics: Declaring tools and writing descriptions the model can use · The tool-calling loop: request, execute, return, continue · Parallel tool calls and ordering · Validating tool arguments before execution — never trust them · Returning errors the model can act on · Termination conditions, step limits and runaway loops · Hosted tools: file search, web search, code execution and their trade-offs · Agent frameworks and SDKs versus a hand-written loop · Multi-agent handoffs and when they are worth the complexity · Observability: tracing every step, tool call and token · Human approval gates for irreversible actions
Grounding answers in your own material, which is what most enterprise LLM projects actually are. Embeddings and vector search, chunking strategies that preserve meaning, hybrid keyword and vector retrieval, reranking, citation, and the discipline of evaluating retrieval quality on its own before blaming the model.
Topics: Embedding models, dimensions and cost · Vector stores: pgvector, managed services and the hosted file search tool · Chunking strategies and what each one destroys · Metadata, filtering and access control at retrieval time · Hybrid search: combining keyword and vector retrieval · Reranking and its effect on answer quality · Grounded generation, citation and refusal when context is insufficient · Measuring retrieval quality separately from generation quality · Freshness, incremental indexing and deletion · Multi-tenant retrieval and preventing cross-tenant leakage · When retrieval is the wrong answer and fine-tuning or a query is right
The discipline that turns opinion into evidence. Building a test set that reflects real traffic including the tail, choosing scoring methods that match the task, using a model as a judge without trusting it blindly, and running the whole thing in CI so a prompt or model change cannot silently make things worse.
Topics: Building an evaluation set from real traffic, including failures · Deterministic scoring: exact match, schema validity, containment, similarity · Rubric scoring and model-graded evaluation · Blind spots in model-graded evaluation and how to calibrate it · Human review protocols and inter-rater agreement · Measuring groundedness and hallucination rate · Regression suites for prompt, model and retrieval changes · Running evaluations in CI and setting a blocking threshold · A/B testing, shadow traffic and online metrics · Capturing production failures back into the evaluation set · Evaluating cost and latency alongside quality
Making the economics work at real volume. Where tokens actually go, prompt caching and batching, streaming for perceived latency, routing cheap requests to cheap models, and the capacity planning that stops a successful launch from producing an unpleasant invoice.
Topics: Token accounting: input, output, cached and reasoning tokens · Attributing spend to features, tenants and users · Prompt caching: structuring prompts so the cache is actually hit · Batch processing for asynchronous, high-volume work · Streaming and time to first token versus total latency · Model routing and cascading from cheap to expensive · Context discipline: summarisation, truncation and retrieval instead of stuffing · Concurrency, rate limits and queueing under load · Caching at the application layer: exact, semantic and negative caching · Capacity and cost modelling before launch · Budget alerts, spend limits and graceful degradation
What has to be true before the feature is allowed out. Prompt injection and why it is an architectural problem rather than a prompting one, data handling and residency, moderation and abuse controls, and the documentation and monitoring that internal risk functions and regulators now expect.
Topics: Direct and indirect prompt injection, demonstrated · Architectural mitigations: least privilege for tools, isolation, approval gates · Untrusted content handling and output encoding · Data exfiltration through tool calls and rendered output · The moderation endpoint and layered content filtering · Input and output guardrails, and where each belongs · Data retention, training-data settings and residency options · Consent, personal data and third-party processing obligations · Abuse, rate limiting and per-user quotas · Production monitoring: quality drift, refusals, injection attempts, spend anomalies · Documentation, risk assessment and the audit trail · Incident response for an AI feature behaving badly
We rebuild the agenda around the tools you actually run.
Request a custom agendaRun one real task across fast, general and reasoning-oriented models, and produce a table of quality, latency and cost that justifies a choice.
Force strict schema output, validate on the client, then break it deliberately — truncation, refusal, timeout, 429 — and handle every case without crashing the caller.
Build a tool-calling loop with argument validation, recoverable error returns, a hard step limit and full tracing, then watch it recover from a failing tool.
Build a retrieval pipeline over real documents, measure recall and precision at k, add reranking and access filtering, and only then tune the generation prompt.
Build a scored evaluation set from real traffic, wire it into a pipeline, and have it reject a deliberately worse prompt while reporting cost and latency.
Run direct and indirect prompt injection against a tool-enabled assistant, exfiltrate something you should not be able to, then fix it with architecture rather than wording.
Ship one LLM feature with structured outputs, retrieval, tools, an evaluation harness in CI, cost controls, guardrails, monitoring and a launch-readiness document.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.