AI Workflow Development Engineer (Intern)

SC Innovators is a machine building company in Chandigarh, set up in 2017 and in industrial automation since 2021. We design and build special purpose machines, automated assembly and testing systems and electrical control panels for manufacturers, and supply industrial components.

We automate other people’s factories for a living. This role exists because we are now doing the same thing to our own office: the quotation desk, the purchase cycle, the store, the service call queue and the reporting that sits on top of all of it.

Our team is small and hands-on. Nothing you build here disappears into a backlog — it either runs or it is switched off.

You will design, build, deploy and operate AI workflows that do real work inside this company: reading incoming enquiries and drawings, drafting quotations, chasing vendors, keeping the store register honest, summarising service calls, and producing the weekly numbers the management runs on.

This is not a research internship and it is not a prompt-writing internship. A workflow you build will be handed to a colleague who is not technical, who has a job to do, and who will tell you plainly when it fails. You own it from the idea to the day it runs unattended — including the cost it incurs, the mistakes it makes and the recovery when it breaks.

We are explicit about this, because it is the whole basis of the offer. This internship carries no stipend. What it carries instead:

• A production environment. Company cloud account, compute, and a real budget of model and API credits under your own keys. You will not be rationing a free tier or watching a student credit balance. Cost discipline will be expected of you — but the constraint will be engineering judgement, not a locked meter.
• Access to real company systems. Our email, our drive, our CRM and task boards, our purchase and store records, our quotation history — under a signed confidentiality undertaking and with a named approver for anything that writes to a live system. A college project cannot give you a messy, contradictory, real dataset with people depending on it. We can.
• Real users and real consequences. Your workflows will be used daily by sales engineers, the store keeper, the service team and the directors. You will get feedback of a kind no evaluation dataset produces.
• A workflow running in a real organisation, with your name on it. At the end of six months you will have something specific and verifiable to show: a system that is live, the measurements that prove it works, the cost per run, and a written account of what you got wrong on the way. This is worth more in a hiring conversation than any certificate.
• Direct mentorship and review. Weekly one-to-one review with the Director, and access to the engineering team for the domain knowledge behind what you are automating.
• Certificate, a detailed written reference, and first claim on a paid role. Interns who deliver are the first people we consider for the paid AI Workflow Engineer position when it opens, and the internship counts as the probation.

What this offer does not include: a stipend, a travel allowance, a guaranteed job, or credit for work you did not do. We would rather say that clearly now than have you discover it in month two.

1. Understand the Process Before Automating It

• Sit with the person who currently does the task — the sales engineer, the store keeper, the service coordinator — and map what they actually do, including the exceptions they handle without noticing.
• Separate the part of the work that is a rule from the part that needs judgement. Most of what looks like AI work turns out to be a form, a lookup and three conditions.
• Write down the current cost of the task in time and money, and the failure cost when it goes wrong. This is the number every later decision is measured against.
• Say so plainly when a task should not be automated, or should be automated without a model in it.

2. Design the Workflow

• Decide the architecture: a fixed deterministic pipeline, a pipeline with a model at one or two uncertain steps, or a genuine agent with tools — and be able to defend the choice on cost, reliability and reviewability.
• Define every step’s inputs, outputs, data contract, failure behaviour, retry policy and human checkpoint.
• Decide where a human must approve before anything is written to a live system, and design that approval so it takes seconds, not minutes.
• Design for the failure cases first: the malformed PDF, the vendor who replies in Hindi, the duplicate enquiry, the API that times out, the month where volume triples.

3. Build It

• Implement workflows using the company’s chosen stack — Python, the Claude API and other model APIs, MCP servers and connectors, workflow orchestration tooling, Google Workspace, spreadsheets and databases, and the automation platforms we standardise on.
• Integrate with the systems the business already uses: email, drive, CRM and task boards, accounting and store records. Handle authentication, scopes, rate limits, pagination, retries and idempotency properly.
• Where a connector does not exist, build one — including writing or extending an MCP server so that the same capability can be reused by the next workflow instead of being rewritten.
• Write structured, validated outputs. A workflow that emits free text into a business process is an unfinished workflow.
• Keep prompts, schemas and configuration in version control with the code. No workflow may depend on something that exists only in one person’s browser tab.

4. Prove It Works Before It Is Trusted

• Build an evaluation set from real historical cases, including the awkward ones, before the workflow goes live.
• Define what “good enough” means numerically for that task — accuracy, escape rate, cost per run, latency — and agree the threshold with the person who owns the process.
• Run the workflow in shadow mode alongside the human, compare, and only then move to assisted mode and finally to unattended running.
• Keep a regression set. A change that improves one case and quietly breaks four others is a failure, and only a regression set catches it.

5. Run It, Watch It, and Pay for It

• Instrument every workflow: run logs, traces of each step and tool call, versions of prompts and models, inputs and outputs retained for replay.
• Monitor success rate, human edit rate, latency and cost per run. Report them weekly in a form the management can read without translation.
• Track spend against budget and take the cost levers deliberately — caching, batching, model routing, prompt size, and simply removing model calls that a rule can do for free.
• Handle incidents: when a live workflow misbehaves, stop it, contain the damage, tell the affected person, fix the cause, and write down what happened.

6. Security, Confidentiality and Safe Automation

• Treat everything a workflow reads from outside — email bodies, attachments, web pages, tool results — as untrusted input that may attempt to steer the model. Design so that it cannot.
• Apply least privilege on every credential and connector. No workflow gets write access it does not need.
• Handle customer drawings, pricing and vendor terms under the confidentiality undertaking. Nothing commercially sensitive leaves approved systems.
• Never let an automated step perform an irreversible or financially binding action — a purchase order, an outgoing customer email, a payment — without a defined human approval.

7. Document and Hand Over

• Maintain a plain-language operating note for every workflow: what it does, what it cannot do, how to stop it, what to do when it fails, and who to call.
• Keep the technical documentation current: architecture, data flow, connectors, schemas, prompts, evaluation results and known limitations.
• Build so that the next person can take it over. Work that only you can run is not finished work.

• Pre-final year, final year, or a graduate within the last 12 months. Branch is not a filter; demonstrated ability is.
• Strong mathematics. Comfortable and quick with ratios, percentages, rates, probability, expected value, weighted averages and orders of magnitude — and able to do it under time pressure without a calculator. This is tested directly in selection and it is not negotiable.
• Programming ability in Python sufficient to read an API’s documentation and make it work: HTTP requests, JSON, error handling, file and data handling, basic scripting. You do not need to be a software engineer; you do need to be able to build something that runs.
• Practical, self-taught experience with AI systems. You have actually built something — not only used a chatbot. You should be able to speak concretely about prompting, context limits, structured outputs, retrieval, tool calling, agents, connectors and where each one fails.
• Reasoning and problem solving well above your year. Able to take an ambiguous business problem, ask the three questions that matter, and structure a solution before writing any code.
• Learning speed. Most of what this role needs, you will learn during the role. The selection process measures how fast you absorb something unfamiliar and then use it correctly.
• Written clarity in English. You will write specifications, operating notes and weekly reports that non-technical colleagues must be able to act on.
• Ownership. Willingness to be the person responsible when a live workflow fails at 9 a.m. on a Monday.

• Basic accounting and commercial literacy — debit and credit, profit and loss versus balance sheet, gross margin, the purchase order → GRN → invoice → three-way match cycle, GST basics, cash versus accrual, working capital. This is a significant plus: almost every workflow here touches a quotation, a purchase, a stock record or a payment, and an engineer who understands what those documents mean designs far better systems than one who does not.
• Experience with MCP servers, agent frameworks, workflow orchestration tools, or low-code automation platforms (n8n, Make, Zapier, Power Automate).
• Retrieval systems: embeddings, vector search, hybrid search, reranking, document chunking and parsing of real-world PDFs.
• Git, APIs, databases (SQL), spreadsheets at a serious level, and basic cloud deployment.
• Any exposure to manufacturing, industrial automation, PLCs, CAD, or a family business in engineering or trading.
• Evidence of teaching yourself something hard without a course telling you to.

• Says “I do not know” quickly, and then goes and finds out.
• Measures instead of assuming. Distrusts a workflow that has only been tested on five examples, including their own.
• Tells someone immediately when something is broken, especially when they broke it.
• Curious about the business, not only the technology — asks why the quotation is made that way before replacing it.
• Careful with other people’s money and other people’s data.
• Finishes. An 80%-complete workflow that nobody uses has zero value.

We interview few and test hard. The process is designed to find high aptitude and high motivation, not polished résumés.

• Application and short written questions — submitted with your CV.
• Written selection paper (2 hours 30 minutes, on-site, closed book, no devices) — quantitative reasoning and problem solving; a learn-it-here-and-apply-it section; AI systems, agents, connectors and MCP; applied workflow design and debugging; basic business and accounting literacy.
• Take-home build task (72 hours) — a small, real workflow. AI assistance is permitted and must be declared; you will be required to defend and modify your own submission live.
• Interview (75 minutes) — build walkthrough, a live learning exercise, reasoning under hints, and a frank conversation about motivation, availability and what you want out of the six months.

The paper is deliberately harder than a normal campus aptitude test. Candidates who do not clear the quantitative and reasoning floor are not taken forward, regardless of what else is on their CV.

• Send your CV to [email protected] with the subject line “Application — AI Workflow Intern”.
• For any query about the position, call or WhatsApp +91-9855104671.
• In the body of your email, answer these five questions in your own words. Short and specific beats long and general:
  • Describe something you have built with AI that actually ran — what it did, what broke, and what you changed.
  • What is the hardest thing you have taught yourself without a course, and how did you go about it?
  • What limits you most today — credits, compute, access to real data, or something else? What would you build if that limit were removed?
  • This internship is unpaid for six months. Tell us honestly why that works for you and how you will sustain it.
  • How many hours a week can you commit, and on which days?
• Attach links to anything you have built: a repository, a demo video, a deployed workflow, a write-up.
• Applications that are visibly written entirely by an AI, with no specific detail from the candidate’s own experience, are not shortlisted. Use whatever tools you like to write clearly; the content has to be yours.

Apply on this website Email your CV