Tuotr — Build one system. Explain it in an interview.

Before you pay again

You already paid for a course.

A course can teach the words. An interview asks for one system you built, and for the details of that system. That is what is still missing.

You watched the videos. You finished the exercises. You can say what RAG means, and what a prompt is, and what a tool call is. That study was not wasted. It is also not what the interviewer is asking for.

The interviewer does not ask you to define the word. They ask what your system looked up. They ask which document or record the answer used. They ask what a tool was allowed to read, and what it was allowed to change. They ask how you knew an answer was wrong, and what you changed after that. If your only example is a course exercise, those answers stay thin. The interviewer can hear that.

The residency is three months in the studio. For those months, this is your work. You build one system. You write the steps. The model does the step you gave it. Sunil reads what the system does, in the room, and tells you when a step is not good enough. You change it. You keep going until you can explain it in plain words.

You are paying for that system, that review, and the time in the studio. The thing you take to the interview is the system you can explain. A certificate beside the ones you already have does not answer the question.

If you are still looking for a recorded course you can do at night, this is the wrong page. Read the modules, the fee, and the questions below before you write. Sunil would rather you decide with the details in front of you.

Three months

What you will be able to say.

Module 1 is enough for “Tell me what you built.” You can stop there. These are the four answers you should be able to give, from your own system, without guessing.

01

What it looked up

The interviewer asks where the answer came from. “It used AI” is not an answer. They want the document, the record, or the search.

You will be able to name what your system looked up, and why that source was the right one. You will also be able to say what happens when the search finds the wrong thing, or finds nothing useful. You decided that. It is written down.

02

What a tool could change

The interviewer asks what the system was allowed to do. A tool that can send an email, change a record, or spend money is a different system from a tool that can only read.

You will be able to say, for each tool, what it may read, what it may change, and what must wait until a person says yes. You wrote those rules. Sunil will have already asked you the same question in the studio.

03

How you knew it was wrong

The interviewer asks for a time it failed. They want the check, not a feeling that the answer “looked odd.”

You will be able to point at the check: the same question run again, a rule the draft had to pass, or a count of which step failed. You will know the difference between a bad prompt, a bad search, and a tool that did the wrong thing.

04

What you fixed

The interviewer asks what you changed, and how you knew the change worked. “I tried a few prompts” is the answer a course leaves you with.

You will be able to name the change: the prompt, the step, the tool rule, or the search. Then you will be able to say how you checked that same case again. Sunil does not accept the work until that story is true.

These four answers are the interview. Three months is enough to have them, if the three months are spent on one system and on the review. You do not need the second module to say them. The second module is for a later question: how you would run that system for other people. That question is real, and it is optional.

One system

What you actually build.

One system, with one job. Not five small demos, and not a tour of every word from a course. The words come up because the system needs them.

The job: The system does one real piece of work. You can say what that work is in one or two sentences. If you cannot, the system is not clear yet, and that is what the review is for.
The lookup: It finds the document or record the answer needs, and it stays inside what it found. You can show a case where the search was right, and a case where it was weak and the system refused to guess.
The tools: Each tool has a written rule: what it may read, what it may change, and what must wait for a person. A tool is not “the model decided to do something.” You connected it, and you set the limit.
The steps: You write the steps. Each step has a job, a tool, and a place to stop. The model does the step you gave it. It does not choose the next step. When an interviewer asks how the work is organised, you walk them through steps you wrote.
The check: You have a way to see that a turn was wrong. You can read that turn from the prompt, through the lookup and the tool, to the answer. Then you can say which step you fixed.
The note: You write down what the system is allowed to do. That note is what you can say in an interview, because it matches the system. Sunil reads the note against the system, the way an interviewer will.

Your resume names this system. You built it, and you can explain it. The About page is about the training: the three months, the review, and what you leave with.

The two modules

Build first. Deploy if you continue.

Build is ₹90,000 + GST for three months. Deploy is ₹1,80,000 + GST for three more months, and only after Build. GST is added on top of each fee. The two fees stay separate. This page does not add them together, and it does not fold the tax into the number.

Module 1

Build

3 months, full-time

₹90,000 + GST

You build the one system, and you practise explaining it. Sunil reviews it with you. When you can answer the four interview questions from that system, Module 1 has done its job. You can stop here. Module 1 is enough for that interview.

The list below is what you use on that system. An interviewer uses these words. You will know them because you used them, and because Sunil asked you to explain them on your own work.

Prompt engineering, RAG, tool calling, MCP, reflection, and workflows.

What you will learn

Prompt engineering. Write the prompt for the job. Change it when the answer is wrong. In the interview you can show the prompt you started with, and the prompt you kept, and you can say why you changed it.
RAG. Find the document or record the answer needs. Stay inside what you found. You can name the source, and you can say what the system does when the search is weak or empty.
Tool calling. Say what each tool may read, what it may change, and what must wait for a person. You wrote those limits. You are not guessing them in the interview.
Workflows. You write the steps. Each step has a job, a tool, and a place to stop. The model does the step you gave it. It does not choose what to do next. That is the way Sunil builds: the person decides the order.
MCP. Connect the model to a real service. The tool has clear rules. You can say which service it talks to, and what it is allowed to do there.
Embeddings. Search by meaning, not only by the same words. You can say when a match is too weak to use, and what the system does instead of guessing.
Task decomposition. Split the job into steps. You decide which step is a model, which step is a tool, and which step waits for a person.
Reflection. Ask the model to check a draft against rules you wrote. Then ask it to write the next version. You can show a draft that failed the check, and the version after the fix.

Module 2

Deploy

3 months, full-time, after Build

₹1,80,000 + GST

You take the system from Module 1 and put it where people can use it. You cannot start here. Build comes first, because there is nothing to deploy until that system exists and you can explain it.

This module costs more because the work is different, and because it is another three full months. You are no longer learning how to answer “what did you build.” You are learning how that system runs: what it costs, what happens if the model changes, what happens when more people use it, and how you find the step that failed.

Deployment, AI FinOps, changing models, scale, evals, and error analysis.

What you will learn

Deployment. The basics of putting an AI product where people use it: a place to run it, a release, a health check, and a way to go back. You can say what you shipped, and what you would do if the release was bad.
AI FinOps. See what models, cloud, and APIs cost. The money should match the work it pays for. You can point at a cost and say which step caused it, and whether that step was worth it.
Changing models. Change the model, or the company that provides it. Then check that the steps still do the same job. You can explain what you compared, and what you refused to assume.
Scale. More people and more requests should not break the steps you wrote. You can say what you expected to break first, and what you changed so it would not.
Evals. Check the same turn again: the prompt, what was found, the tool call, and the answer. You can show the check you trust, and a case it caught.
Error analysis. Read the failed runs. Count which step failed. Fix that step first. You can say why you did not start with a random prompt change.
Traces. Read one turn from the prompt, through the tool, to the answer. When something is wrong, you can show the turn instead of describing a feeling.
Guardrails. Stop an action that must wait, before an email, a record change, access, or spending money. You can say which actions your system is not allowed to take alone.
Observability. When something goes wrong, use the logs to see which step did it. You can walk someone from the problem to the step.
Human-in-the-loop. A person must say yes before a step that cannot be undone. You can name those steps in your system, and say why they wait.
Audit. Keep a record that the application itself cannot change. You can say what a later reader can prove, and what they cannot.

Pay ₹90,000 + GST if you want the system and the four answers. Pay ₹1,80,000 + GST as well only if, after Build, you want the three months on deployment, cost, model changes, scale, and finding failed steps. You do not pay the second fee to “finish” the first interview. Build already covers that interview.

If you do both, you pay both fees, each plus GST. There is no third price on this page. Your rent, food, and travel in Bangalore are separate. Those are explained with the fee below.

Your resume

Your resume names your system.

You built it. You wrote the steps. Sunil checked it the same way an interviewer will ask you about it. That is what you say when they ask, “Tell me what you built.”

On the resume, name your system and say what job it does. Be ready to talk about the lookup, the tools and their rules, the check that showed a failure, and the fix. That is a true line. It is also a line you have already practised, because Sunil asked you those questions before you left.

Write only what you can walk through. If you cannot explain a step, leave it off the resume. The interviewer will ask the next question, and you need an answer from the system you built.

A course certificate does not replace this line. You may already have certificates. The person on the other side of the table has seen them. They still ask what you built.

The studio

A week in the studio.

In person at 26 Magrath Road, Bangalore, on weekdays. Full-time means these months are your work. The group stays small enough that Sunil reviews your system. You are in the room with him. The work is not a recording you watch later.

Work: You work on your system, on the computers in the studio. You are building the lookup, the tools, the steps, and the check. You are not collecting slides.
Review: Sunil reads what the system actually does. He asks the interview questions early: what it looked up, what a tool could change, how you knew it was wrong, what you fixed. If the answer is vague, the review is not finished.
Fix: You change the system until Sunil is satisfied. A step that you cannot explain is a step you rewrite. This is the part a video course cannot do, because nobody is reading your system.
Write: You write down what the system is allowed to do. The note and the system have to match. That note is what you can say later without inventing a better story than the one you built.

There is no start date on this page. After you talk, Sunil tells you when there is a seat. The computers, GPUs, coding tools, and API keys are in the studio. You do not bring a laptop to do the work, and you do not open your own cloud bill to learn.

Before you write

Is this the right room?

Sunil reads your note and talks to you before you pay. He may say yes. He may say this is not the right room. A clear no is more useful than another course that does not fit.

You have already studied

You know the words, or you have finished a course, and you still cannot explain one system you built. That is the person this is for. You do not need to arrive as an expert. You do need to arrive ready to build.

You can be in Bangalore

Weekdays, for three months, at Magrath Road. Full-time. If you need evenings, weekends, or a class you can watch from another city, say so in the first message. This studio cannot become that.

You can redo the work

Sunil will tell you when the system is not good enough. The month is useful only if you change it. The review asks the same kind of question an interviewer will ask. The first draft is rarely the one you keep.

The fee

What the fee pays for.

Build is ₹90,000 + GST. Deploy, if you continue, is ₹1,80,000 + GST. Nothing on this page is a GST-inclusive total. Tax is added on top when you pay.

Included: Sunil’s teaching, a seat in the studio, the computers, the GPUs, the coding tools, and the API keys. For normal use, you do not get a second bill for those.
Normal use: Normal use means the study and the system you build in the residency: running it, checking it, and fixing it. If you want the machines or the keys for a job, a company project, or anything outside that work, ask Sunil first. He will say yes or no before there is an extra cost. Do not assume a private project is covered.
Your laptop: You do not need to bring a laptop for the work. The hardware is in the studio. You also do not need to buy API keys to keep up with the class.
Not included: Your stay in Bangalore is yours: rent, food, and travel. The fee is the residency. GST is also extra, on top of the fee for the module you take.
When you pay: There is no payment on this website. You write or call, you talk, and you hear whether there is a seat and when it starts. Pay after that conversation, not before.

A job

A job may come later. We do not promise one.

You are paying so you can explain one real system. After that, there may be a conversation about work. That conversation is not a job offer. It is not a salary. It is not a number of openings. It might not happen.

A promise of a job would be a false claim. That is against the law. We will not make that promise on this page, on a call, or in an email. If you need a guaranteed job in exchange for the fee, do not pay. This is the wrong place for that exchange.

Write to Sunil when you know which question you still cannot answer, and whether you can be in Bangalore for three months.

Write to Sunil

Questions

Questions people ask before they pay.

These are the doubts that usually show up after a course that already cost money. The longer answers are in the sections above. This is the short form, so you can check you did not miss one.

I already did a course. Why would I pay again?

Because the course left you with the words, and the interview asks for a system. If you can already sit down and explain one system you built — what it looked up, what a tool could change, how you knew it was wrong, what you fixed — you do not need Module 1. If you cannot, another video will feel familiar and leave you in the same place.

Here the three months are spent on one system, in the room, with Sunil telling you when the explanation is not good enough.

Is Module 1 a waste if I do not take Module 2?

No. Module 1 is the system and the four answers. That is the interview question “Tell me what you built.” You can stop. You keep the system you built and the practice of explaining it.

Module 2 is a second three months, and a second fee of ₹1,80,000 + GST, for deployment, cost, changing models, scale, evals, and error analysis. Take it only if you want that later question. You cannot skip Build and start with Deploy.

Why does Deploy cost twice as much?

It is another three months, full-time, on a harder job: putting your system where people can use it, seeing what the models and APIs cost, changing the model without breaking the steps, and finding which step failed. The fee is ₹1,80,000 + GST, on top of the Build fee if you do both. GST is added on top of each number. We do not publish a combined tax-inclusive total.

What do I write on my resume?

Name the system you built in the studio, and the job it does. Be ready to say what it looked up, what a tool could change, how you knew it was wrong, and what you fixed. Write only the parts you can explain. A course certificate does not answer that question.

Do I bring a laptop and pay for API keys?

No. The studio has the computers, GPUs, coding tools, and API keys. Normal use of those, for the system you build here, has no extra charge. Your rent, food, and travel in Bangalore are not in the fee. If you want the keys for work outside the residency, ask first.

Can I do this online, or after work?

No. It is in person, on weekdays, full-time, at 26 Magrath Road, Bangalore. The review only works if Sunil can read the system with you. If you cannot be here for three months, say that in the first note.

Will I get a job, a salary, or a certificate?

A job may be discussed later. We do not promise a job, a salary, or a number of openings. A promise like that would be a false claim, and that is against the law.

What you leave with is the system, the written note of what it is allowed to do, and the ability to explain it. That is the point of the fee. A certificate does not answer the interview.

When does it start, and can Sunil say no?

There is no start date on this website. You talk first. Sunil tells you when there is a seat. He can also say this is not the right room — if you cannot be here full-time, or if what you want is a job guarantee. You do not pay before that conversation. There is no form and no payment button.

What should I write to Sunil?

Four or five lines are enough. What you have already studied. The interview question you cannot answer. Whether you can be in Bangalore on weekdays for three months. Whether you are asking about Build only, or Build and then Deploy. Simple English is enough. The contact page has the email, the phone, and LinkedIn.