Raza SOR use cases

Who is Raza?

Raza Rizwan is an AI engineer from Karachi, Pakistan. He works at Canz Marketing, a digital marketing agency, as a Forward Deployed Engineer. He has worked in AI for six years, starting with simple image classifiers in 2020 and moving through machine learning, MLOps, computer vision, generative AI, and AI agents. Today he builds AI employees that run real business work every day.

What does he actually do?

He builds AI systems that hold a real job inside a business. Then he puts them where the team already works: ChatGPT, Claude, Codex, WhatsApp, and Gmail.

"Forward deployed" means he does not hand over a demo and leave. He works inside the customer's real workflow, connects the AI to their tools, deploys it, and stays responsible for what ships. His own rule: real deployment is 20% model and 80% process, integration, and accountability.

The problem he solves

AI made writing code fast. But delivering software is still slow, because a person has to type every step, re-explain the project after every reset, and clean up the mess. Raza puts the whole delivery process inside the AI, so it researches, designs, builds, tests, and deploys the same way every time. A person only steps in at the approval gate. On one real project, that was 7 out of 10 steps with no human, or 70%.

The three things he builds

1. AI employee – Owns one full job from start to finish, on the channel the team already uses. For a repeatable job that eats up someone's whole day.
2. AI agent – One worker for one task. It decides the next step, uses approved tools, and stops for a person at the gate. For one task that repeats and has a clear finish.
3. MCP connector – A server that puts your company's process and rules inside ChatGPT, Claude, or Codex, so any AI your team uses follows your way of working.

Sources: Who Raza Rizwan is, Journey overview, 2026: AI employees and connectors

Here is what you can pick up and use right now.

1. The raza-sor record (an MCP server)

This is Raza's own knowledge base, and any AI you already use can read it. You plug it into Claude, ChatGPT, Codex, or Claude Code, and it gets three tools: search, outline, and read.

What is inside:
- A method for counting how much of any workflow AI can do. You write the steps down, tag each one AI, DECISION, or TYPING, count, and mark where a human must say yes.
- The "Build your agent" room: how to turn one step into a working AI agent on the OpenAI Agents SDK, with tests, evals, and deployment.
- The AI Prompting Guide 2026, thirteen ideas for writing better instructions.
- What Raza builds, how he works, and his six-year journey.

How to get it: go to razarizwan.com/access, enter your email, type the code you receive, and you get an address with your key inside. In Claude Code it is one command. In other tools, paste the address into MCP or connector settings.

2. The build-your-agent skill

The skill you are using right now. It reads the record and walks you through building one AI worker in ten steps. It stops for your approval before any code is written, and again before deploy.

3. The AI workflow audit

The first step with Raza, and it is small on purpose: one workflow, 15 minutes, two numbers back. You describe one job that repeats in your business. The steps get written down, tagged, and counted. You walk away with your own step table, the list of steps a person should keep, the gates where a human must say yes, and a plain recommendation: build a pilot, or don't. If automating is not worth it, the audit says so.

You can do the first pass yourself in twenty minutes with the counting method in the record, or hand your answers to any AI connected to the record and it will build the table with you.

How to start: book at razarizwan.com/book, or send the six answers by email or WhatsApp.

Sources: Attach the record, The AI workflow audit, Overview, 2026: AI employees and connectors

Raza works the same way with every client. The method exists because most AI projects fail in the last mile, not in the demo.

The four moves, from first call to handover

1. Audit (the first call, 15 minutes)
You describe one job that repeats in your business. Together you write down the steps as they happen today, tag each one AI, DECISION, or TYPING, and count. You leave with your own step table, the gates where a human must say yes, and a clear answer: build a pilot, or don't. If it is not worth automating, the audit says so.

2. Pilot
One limited workflow gets built, with the integrations, approvals, logging, and evaluation it needs. Then it is handed over. Nothing else starts until this one is measured and working.

3. Production
The live tools get connected, permissions get set, the failure paths get tested, everything gets documented, and your team gets prepared to run it.

4. Optimize
Review what failed, improve the checks, and extend only what proved useful.

Each stage earns the next. You never pay for stage two before stage one shows a number.

The rules underneath

• One workflow first. Prove it in production before touching a second one.
• Success is written down before any code. What goes in, what comes out, what "done" looks like, what proves it, and where a person stays in control.
• The server enforces the process. The system does not trust the AI to behave. A server refuses work done out of order, placeholder text, secrets, self-reported scores, and claims with no evidence. Any edit after approval cancels the approval until the checks run again.
• Humans sit at decisions, not at the keyboard. In a typical run the human steps are the brief, the design approval, and the go-live. Everything between is done and checked by the system.
• State lives outside the chat. Every build has an ID and its progress lives in a database, so a new session picks up from the last finished step instead of re-explaining the project.
• Counted, not guessed. "70% automated" is a real count from a real ten-step run, not a slogan.

What he refuses

A demo with no path to production. Made-up or rounded-up numbers. Publishing the insides of a client's system. Automating a decision that should stay with a person.

How to start: book the 15-minute audit at razarizwan.com/book.

Sources: How I work, The AI workflow audit

1. Can Raza automate my work, and how much?

Yes, and the honest answer is a number that belongs to your business, not a guess. The method is the same for any industry: name one job that repeats, write its steps as they happen today, tag each one AI, DECISION, or TYPING, and count. Five worked examples land between 64% and 80%: web design 73%, recruitment 64%, e-commerce catalogue 80%, SaaS support 78%. Every human step left is a decision, like price, taste, or a final yes. Never typing. You can do the first pass yourself in twenty minutes, or do it with Raza in the 15-minute audit.

2. Why trust him? Show proof.

• Six years on GitHub: 111 original repositories, 75 public, 36 private, from a cat-vs-dog classifier in 2020 to live business connectors in 2026. Anyone can check github.com/rrizwan98.
• Every number in his record carries its date and source. He refuses to count commits, stars, or streaks because they are easy to game.
• The "70% automated" claim is a ten-step table from a real run, with each step named and tagged. Not a slogan.
• Client outcomes are published only when verified, never sold before delivery.
• The audit comes first, and if automating your workflow is not worth it, the audit says so. That is the opposite of a sales pitch.

3. Contact and price

• Email: rrizwan1998@gmail.com
• WhatsApp: +92 303 2206662
• LinkedIn: linkedin.com/in/raza-rizwan98
• Book the 15-minute audit: razarizwan.com/book
• Based in Karachi, works with teams anywhere.

Pricing is not in the record. The first step is the free audit call; costs come up after your workflow is understood, never before.

Sources: Count your own workflow, Worked counts, Journey in numbers, Contact

This one stops at the first gate, and the record names your exact case as its example.

Gate 1a: AI or a regular tool? The rule is: if the task is one exact step that is the same every time, a regular tool is faster and more reliable. The record's own example is "changing every 2024 to 2025 is find-and-replace." Your task is the same thing, one year later. There is no judgment in it, no mixed file types to understand, and a tool already exists.

So this is not an agent job, and the skill says to stop here and offer the cheaper path. The cheapest mistake to fix is the one you catch before you start.

The cheaper path, in one command

Inside your repo:

git grep -l "2025" | xargs sed -i 's/Copyright (c) 2025/Copyright (c) 2026/g'

Or, in VS Code: Ctrl+Shift+H, search Copyright (c) 2025, replace with Copyright (c) 2026, Replace All.

Two tips:

• Match the full phrase ("Copyright 2025" or "© 2025"), not the bare number, or you will change version numbers, dates in changelogs, and test data.
• Run git diff afterwards and skim it before you commit. That is your "done when" check, and it takes under a minute.

When this would become an agent

Only if the job stops being one exact step: for example, if you had fifty repos with different copyright formats, some files that must be skipped by rule, and the task ran every January without you. Then Gate 2 (every year, same shape, worth it) and Gate 3 (works from, want at the end, done when) would be worth running. For one repo, one year, one pattern, find-and-replace wins.

Sources: Is this an agent problem? Three gates before you build

I can't skip the gate. It is one of the skill's non-negotiables, and the skill's own scope line says to stop once the gates send a task to a chatbot. The good news: the gate takes ten seconds here, and the cheaper path is the answer itself, which I can give you right now.

Gate 1b, agent or chatbot? The record's rule: a chatbot answers, an agent does. If you only need to know something, a draft, or ideas, that is answer work. Only action work, where the tool must open your files, change them, run something, or use another app for you, is an agent job. Both halves of your request are answer work: an explanation and three drafts. Nothing gets opened, changed, or run. So this is a chat assistant's job, and building an agent for it would be a wasted build.

So here is the cheaper path, done.

How SAML login works (for the team)

SAML is how "Log in with your company account" works. Three players: you (the user), the app you want to use (the Service Provider), and your company's login system like Okta or Microsoft Entra (the Identity Provider). You click login on the app. The app says "I don't check passwords, go ask your company," and sends you to the Identity Provider. You log in there, with your usual password and MFA. The Identity Provider hands you a signed note, called an assertion, that says "this is Raza, verified, here is his email and role." You carry that note back to the app. The app checks the signature, trusts it, and lets you in. The app never sees your password. That is the whole point: one login system, many apps, and when someone leaves the company, IT switches them off in one place.

Three headline options for the landing page

I assumed this is for the Forward Deployed Engineer / AI employee service, since that is what this conversation has been about. Say the word if it is a different page.

1. AI employees that finish the job. You only say yes.
2. 70% of your workflow, automated. Counted, not promised.
3. Stop babysitting your AI. Put the process inside it.

When this would become an agent

If the explainer had to read your actual SAML config and diagrams and produce team docs every time they change, or if headline drafts had to pull from your live analytics and brand file and land in your CMS as drafts, that is action work. Then the gates would be worth running properly.

Sources: Is this an agent problem? Three gates before you build

Your sales lead's agent hits two of the six things that stay with a person in every business, so it cannot be built as asked. It can be built as something smaller and safer.

What stays with a person

• Taste and judgement. Which of two good options fits the client or the moment.
• Relationships. The conversation where trust is built or lost.
• Price and terms. What something is worth to this buyer, and what you will accept.
• Risk and liability. Anything where being wrong costs money, safety, or reputation.
• The exception. The case the procedure did not anticipate. The system should stop, not improvise.
• The final yes. Someone signs before it goes live or reaches a customer.

Applied to the discount agent

"Decides the discount" is price and terms. It stays human, whatever the technology does. "Sends the offer" is the final yes: something reaching a customer. It stays human too. Irreversible and ungated is the one combination that is never allowed, and an offer in a client's inbox is exactly that.

What the agent can do instead

Everything around the decision: pull the client's history, spend, and past discounts; apply the written discount rules and show which tier the client falls in; draft the offer; flag anything unusual; then stop and wait. The sales lead sees the proposal, picks the number, and hits approve. Only then does it send. The model proposes, a human disposes.

One trap to check first

"It needs judgement" is often "nobody wrote it down." Ask the sales lead what they actually consider when setting a discount. If the answer is a list (deal size, margin floor, client tier), that is a rule and the agent can compute it and show its work. If the answer is "it depends, you get a feel for it," it is judgement and it stays with them. Either way, the send button stays with a person.

Sources: What tasks can AI automate? The four conditions, The gate on the one action that moves money

Yes. This one passes all three gates, and it is the clearest agent case you have brought so far.

Gate 1: does it need an agent at all?

Tool or AI? Tickets arrive as free text from two channels, the category takes reading, and "what is missing" changes per ticket. No find-and-replace does that. It is an AI job.

Chatbot or agent? A chatbot would answer "what category is this?" Your job needs the system to read the inbox, write back to the customer, and change the assignment in your help desk. That is action work. Agent.

Gate 2: once, or every week?

All three dials are up. How often: 60 a day, every day. How same: same input shape (a ticket), same steps (read, categorise, ask, assign), same finished result (a routed ticket). Worth it: 60 tickets a day is a person's whole day, and the cost of a mistake, a ticket to the wrong engineer, is visible and reversible. Mode 2, build a worker.

Gate 3: what does finished look like?

Three lines, in your words, to confirm:

• Works from: every new ticket in the support inbox and the web form, as it arrives.
• Want at the end: each ticket carries a category, has the missing details requested from the customer or already present, and sits in the right engineer's queue.
• Done when: at the end of the day, every ticket that arrived is assigned, categorised, and either complete or waiting on a customer reply. Zero in the unassigned pile. Countable in under a minute.

Your run, counted

Four of five, or 80%, as a could-be. Step 05 is the gate: the system recognises the exception (an outage report, a legal threat, a VIP account, a ticket it cannot categorise with confidence) and hands it to a person instead of guessing. That gate is what makes 02 to 04 safe to run without watching.

Before anything is built

The skill needs three proven runs by hand, with dates: three tickets a person triaged the way you describe, so the agent has a real example to match, not an invented one. Your team does this 60 times a day, so those exist. Send me three of them, with the date and what the person did at each step, and the next move is the delegation map.

Sources: Is this an agent problem? Three gates before you build, Worked counts: a SaaS company, first-line support

Gate 3 asks for three lines. They are the target, not the instructions, and later they become the spec. Here they are in your words, with one thing to check on each.

Works from
Every new submission of the website form, as it arrives, all day. Not "our leads": that is too vague. If leads also come by phone, chat, or a partner, say so now, or they stay outside the agent's job.

Want at the end
For each lead, three things exist: a brief in your standard shape (who, what they want, budget or size if given, source, date); an email to the lead asking the two or three details the brief is missing, sent from your address; and a CRM record with the brief attached and the right tag on it.

Done when
The one check, in under a minute: every form submission from today has a CRM record with a tag, and each record is either complete or marked "waiting on lead reply" with the sent email attached. Zero leads in a "not in CRM" pile. Count them and they match the form count.

The gate you should name now

One step in this run is not typing. Deciding which leads are worth chasing, and what to say to a big or unusual one, is a judgement. So the exception rule: if the lead looks like a large deal, a competitor, a complaint, or something the brief template cannot hold, the agent writes the brief, does not send the email, and hands it to a person with a note. That is what makes the automatic emails to ordinary leads safe.

Two things to settle before the spec

Which questions get asked: is it always the same two or three, or does it depend on what the form left blank? If it is a list, the agent computes it. If it is "you get a feel for it," it stays with a person.

Which tag: the tag rule needs to be written down as a rule. "Enterprise if company size over 200" is a rule. "Whatever feels right" is not.

Sources: Is this an agent problem? Gate 3, what does finished look like, What tasks can AI automate? The four conditions