Staff Engineer / Applied AI & Platform Architecture

Agents that survive regulated production.

I am Kamyar, Staff Engineer. I build platforms that hold up where audit trails, data protection and financial exposure are on the line. Applied AI, not ML: I don't train models; I take existing ones into production and keep them correct, affordable and compliant.

Email me github.com/kamyarshahrestani
Night Agent, run topology exit 0
objective plan dispatch worker worktree-1 worker worktree-2 worker worktree-3 verify retry merge
No model decides whether the code is correct. The verifier runs your test command and reads the exit code.
  • In production

    An MCP server with 28 tools behind OAuth 2.1, and a Gemini agent on Vertex AI with cost caps and an eval gate in front of it. Both live for every user since July 2026.

  • EU-resident by design

    Data pinned to europe-west1. Statement bytes live for a turn, embeddings for a session, and no third-party vector store was added to make that work.

  • Not vendor-locked

    The receipt scanner has run on OpenAI and on Gemini. The coding swarm runs on Ollama, Bedrock, Vertex or OpenAI behind one provider registry.

Background

Where the years went.

Senior developer, then technical lead, then Staff Engineer. The same arc each time: own the system, keep it correct under real load and real regulation.

  1. 2019 to now

    Staff EngineerFinlex, Frankfurt

    Insurance. Led the micro-frontend and domain-driven architecture of a multi-tenant, white-label platform (Nx, NgRx), the kind of system where an audit trail is a requirement rather than a feature. Part of the team that took a multi-agent AI system to production on Amazon Bedrock. Support chatbots lifted satisfaction to 80 percent; delivery efficiency up 30 percent, coverage held at 95.

  2. 2018 to 2019

    Senior Full Stack DeveloperJob Frame, Mainz

    Angular in a test-driven environment, .NET Core and MongoDB behind it, deployed to Azure with CI/CD end to end.

  3. 2011 to 2018

    Senior Developer and Technical DesignerTehran

    Finance, travel and e-commerce. Booking platforms and financial tooling on ASP.NET, Angular and SQL Server, plus reporting and database work under real load.

B.Sc. in Computer Engineering, Azad University Karaj. German citizen with an EU passport, so no visa or sponsorship question anywhere in the EU. English fluent, German at B2.

TypeScript, Python, C# / Angular, React, React Native, Expo / NestJS, .NET Core, FastAPI / Firestore, MongoDB, SQL Server / GCP, Azure, AWS / Nx, NgRx, Jest, Cypress, Playwright, pytest / MCP, Vertex AI, LangGraph, Ollama

Two systems in production.

A financial assistant with real hands

Receipts Manager / receipts-manager.com

A finance product I run end to end. The agent gets no tools of its own: it drives the same MCP surface external clients use, so it inherits every scope, rate limit and audit entry the API already enforces.

  1. i

    One deployment, every user's credential.Each bearer token resolves per invocation from session state instead of at construction, so a single agent serves everyone without ever holding a shared credential.

  2. ii

    Scope narrows the prompt and the token together.A session opens bound to one period or budget. Accuracy, least privilege and cost all improve from the same decision.

  3. iii

    No auto-commit path, deliberately.Statement text is attacker-influenceable, so imports are always propose then confirm. A fully compromised model still only produces a suggestion someone declines.

  4. iv

    A hand-designed tool surface, not sixty generated endpoints.Models use a noisy surface badly. Every write is idempotent and logged as the agent's, so a person can trust what it did and undo it.

Solo-built and live: product, API, iOS and web app, release process, and two isolated GCP environments. The MCP connector and the agent reached production in July 2026.

Vertex AI Agent Engine / Gemini 2.5 / MCP / OAuth 2.1 / FastAPI / Firestore / Cloud Run / Expo

An objective is split into non-overlapping tasks. Each runs in its own worker, in its own git worktree, on its own branch. What passes verification merges as an ordinary commit anyone can read and revert.

  1. i

    No model judges its own work.The verifier runs the project's real test command in the worktree and believes only the exit code. Nothing else counts as done.

  2. ii

    Workers never share a checkout.The two ways multi-agent coding systems fail are designed out rather than tuned around. Integration is a merge you can inspect.

  3. iii

    Interrupted runs resume, they do not restart.The orchestrator routes over a typed ledger and checkpoints to SQLite after every node, so a crashed run picks up by thread id.

Measured against a committed goal corpus. The first full run showed most failed attempts died on the verification contract, not on generated code, and that finding reset the roadmap.

LangGraph / Ollama / git worktrees / SQLite / Docker / SSE / Bedrock / Vertex / OpenAI

A coding swarm that reports to a test suite

Night Agent / built at Finlex / private repo

How I build

Four rules I hold to.

  1. i

    Verification beats vibes

    An exit code is the only thing in an agent loop that cannot be talked into agreeing with you. Wherever a model can grade its own homework, it eventually will.

  2. ii

    Scope is a feature, not a guardrail

    Narrowing a session narrows the prompt and the credential together. Accuracy, least privilege and cost all improve from a single decision, made once, at the point a session opens.

  3. iii

    Leave the human on the commit

    Propose then confirm, everywhere the input is attacker-influenceable. Design so that total model compromise still only produces a suggestion someone declines.

  4. iv

    Build with the thing you build

    My own workflow runs on coding agents: tickets planned in the tracker, work dispatched to subagents in separate worktrees, merges gated on CI. Every pattern on this page runs in my own repositories first.

If you are setting up AI in your company.

Most teams have a prototype that works in a demo and a list of reasons it cannot go in front of customers. That list is the work I do. I take a small number of engagements alongside my own products, usually a few weeks, sometimes one long conversation.

Email me
  1. 01

    Your first production agent

    From prototype to something you can widen access to safely: session scoping, a credential the agent cannot leak, propose then confirm for anything that writes, and rollout gates you can actually hold.

  2. 02

    Your API as a tool surface

    MCP over the service layer you already have. OAuth 2.1 with discovery, scopes, rate limits, idempotent writes and an audit trail. Existing clients keep working while the agents arrive.

  3. 03

    EU residency and retention, decided and written down

    Which region, what the model may keep and for how long, whether a new vendor is allowed in. Recorded as decisions your data protection officer can read, not as a hope.

  4. 04

    Cost, evals and vendor independence

    Token caps that return a clean error instead of an invoice, an eval gate before each release, and a provider layer so moving between OpenAI, Gemini or Bedrock is a configuration change.

Tell me what you are building.

info@shahrestani.me GitHub LinkedIn

Open to Staff and Principal Engineer, Applied AI and AI Agent Engineer, and Platform Architecture roles: technical leadership and system ownership rather than people management. Also open to companies that want their AI project set up properly the first time.