INDEPENDENT · ISTANBUL · REMOTE
Put AI
to real work.
I design and build AI systems for teams spending too much time checking information and moving work between tools. The focus is reliable delivery, clear evidence, and control over the decisions that matter.
Bring one recurring process. We’ll discuss where time is lost, what needs human judgment, and whether a custom build makes sense.
Example workflow
- Output
- Lead packet and reply draft
- Next step
- Sales rep reviews the draft
- Output
- Draft reply with policy references
- Next step
- Support agent checks and sends
- Output
- Validated draft or exception packet
- Next step
- Finance reviews in the ERP workflow
Sample data. This walkthrough illustrates the steps and review boundary; it does not show a production run.
From prototype to operation
A model call needs an operating workflow around it
The model can produce an output. Reliable use depends on how work enters, what evidence is checked, and what happens when a step fails.


Under the hood
The controls that make that workflow operable
Capturing work, checking evidence, handling failures, and giving someone ownership of the exceptions.
Capture work reliably
- Durable records
- Scoped idempotency
- Retries
- Recovery ownership
Use the right information
- Permission filters
- Version checks
- Bounded retrieval
- Visible gaps
Control actions
- Policy checks
- Tool limits
- Approval rules
Operate the system
- Evaluation
- Tracing
- Alerts
- Cost visibility
- Rollback ownership
- Capture work reliablyAccepted work is not lost or done twice.
- Use the right informationOnly current, permitted sources, with gaps shown.
- Control actionsNothing consequential happens without a policy check or a person.
- Operate the systemYou can see cost, trace a run and roll back, with a named owner.
The design depends on the process; simple rules are preferable where they solve the problem.

Who I am
Nine years building production software.Applied to AI systems.
I work independently from Istanbul, remotely, with teams across Europe, the UK, and the US. My background is nine years of production software engineering, with a focus on data integrity, failure recovery, observability, security, and maintainable handover. I design the workflow, implement the agreed system, test its failure paths, and make the operating boundary explicit.
Eight design studies show the decisions and validation plans behind that approach.
Handover includes the source code, setup instructions, tests, and operating notes needed for another engineer to take over.
As an independent engineer I have built two such systems for client teams, both still in use: one explains what went wrong behind a production alert and how it should be fixed, the other decides which user sessions are worth an AI analysis. More about my work.
Worked example · sample data
Finding the answer while the customer is still on the call
A support rep gets a discount question mid-call. Here is the exchange, and the point where the assistant stops and hands the decision back.
-
Customer
Can I apply the renewal discount to this account?
-
Assistant
Here is what I can see for this account.
-
Found
The account recordAnnual plan, renewal pending.
-
Found
The discount policy, section 2The discount applies only when retention has authorized it.
-
Not found
Authorization for this accountNothing in the record grants it.
-
Found
-
Assistant · suggested reply
I can confirm that your renewal is pending. I need to check this account’s discount eligibility before I can offer a rate.
The draft stops where the evidence stops.
-
Support rep
I can tell you your renewal is pending. Let me confirm the discount with retention before I quote you a rate.
The rep decides what to say. A missing authorization stays missing, and nothing here turns “not found” into “yes”.
If we piloted this, we would measure
- How quickly a rep gets an answer they can back up
- How often the assistant suggests something unsupported
- How many repeat lookups disappear
- How much checking the rep still has to do
Sample data, not a production run. Whether an assistant can follow a live call depends on the phone system it would sit next to, so that gets checked rather than assumed.
Working together
From one process to an owned system
The first conversation is a description and a reply, not a commitment.
- Understand the processMap the current work, recurring failure, owner, and available examples.
- Validate a small scopeAgree on the output, test cases, review boundary, and measures before expanding.
- Build and checkImplement the workflow, test failure paths, and review it against the agreed criteria.
- Hand over and operateProvide code, setup notes, tests, and an agreed ownership and support plan.
A practical first conversation
Let's build something real
Tell me what happens today, where the work slows down, and which decisions need care. A rough description is enough.
Helpful, not required
- A written process, if you have one
- An anonymized example
- The tools involved
- The failure or delay you want to reduce
- Based in
- Istanbul
- Working with
- Europe, the UK and the US, remotely
- info@bshadmehr.me