Skip to content
Zeeshan KhanSenior Software Engineer

AI Engineering

Enterprise systems that reason, coordinate and act.

I design and build the architecture around language models: domain agents with their own tools and permissions, an orchestration layer that plans across business areas, governed execution against real ERP services, and realtime voice on the same path. What follows is the engineering, not the vocabulary.

Where the engineering sits

I do not train foundation models. I build the layers that turn them into software a business can rely on — routing, agents, tools, permissions, approvals and audit. The models are a dependency; the architecture is the work.

Foundation models

OpenAI · Gemini · Anthropic · DeepSeek

Provider abstraction

Capability-matched routing, not vendor lock-in

Where my engineering lives

JARVIS

Orchestration layer — intent, planning, routing, context

Agents

Tools

Governance

Enterprise software

ERP services, domain logic, data

Foundation models sit below a provider layer; the agentic architecture, agents, tools and governance are the layers built on top.

01 — Progression

From generation, to agents, to coordination.

01 — Language models inside the product

Generative AI

Natural-language interaction, summarisation, drafting and structured output against real business data — in English and Arabic.

02 — Past prompt and response

AI agents

Domain agents with their own instructions, tools, permissions and boundaries, each answering for one business area.

03 — Agents that coordinate

Agentic AI

JARVIS, the orchestration layer, plans across domains, delegates to other agents, executes governed actions and stops for a human when the effect warrants it.

02 — Orchestration

JARVIS: one way in, many domains behind it.

Pick a scenario and step through it. Each path is a real one: the agents, action codes and approval points below exist in the platform’s registry.

What JARVIS is

JARVIS is the central orchestration layer I designed for the ERP — the component that interprets intent, holds context, selects the agent and capability for the job, and manages governed execution. It is not a model. It sits above whichever provider is configured and coordinates the agents, tools and approvals underneath.

RequestFind slow-moving products and prepare a campaign to promote them.

Chat / Realtime voice

JARVIS

Orchestration layer · intent · routing

CRM

Sales

Inventory

Finance

Marketing

Documents

Tool layer · ERP services

Governance

Permissions · policy · audit

Human approval

1 / 6

03 — Agent architecture

What an agent actually is.

An agent is not a prompt. It is a bounded unit with a domain, a tool set, the caller’s permissions, a data policy and rules about what it may do unattended.

  • Identity & domain

    One business area, one set of responsibilities

  • Instructions

    Role, boundaries, refusal conditions

  • Business context

    Company and branch scope injected per run

  • Tools

    Only the registered actions its domain allows

  • Permissions

    The caller’s ERP rights, never the agent’s own

  • Policies

    Data classification, redaction, retention

  • Memory

    Scoped, governed, opt-in per assistant

  • Approval rules

    Which effects may run unattended

  • Execution layer

    Application services — never raw database access

An agent is composed of identity, instructions, business context, tools, permissions, policies, memory, approval rules and an execution layer.

04 — Autonomy

Bounded autonomy, not open-ended.

An agent run plans, calls tools, reads results and decides what to do next — inside a budget. Steps, tool calls, delegations, delegation depth, created records, publications and wall-clock duration are all capped, and the run is cancellable.

  1. 01

    Understand

    Resolve intent against the caller’s scope

  2. 02

    Plan

    Choose the domain, the agent and the sequence

  3. 03

    Act

    Invoke a registered tool, never a free-form query

  4. 04

    Observe

    Read the structured result back

  5. 05

    Adapt

    Continue, delegate, or stop against the step budget

Approve

Any write pauses here

↻ bounded by step, tool-call, delegation and duration budgets

An agent run cycles through understand, plan, act, observe and adapt, bounded by a step budget, and pauses for approval before any sensitive action.

05 — Governance

Autonomy without losing control.

Autonomous should never mean unrestricted. Agents act with the permissions of the person who asked, inside their company and branch scope. Read actions run; write actions are sealed and held for a human.

Agent decision

Permission check

The caller’s ERP rights and company scope

Governance policy

Action effect, risk, budget, data classification

If read

Read effect

Executes directly

Execute

If write

Write effect

Held for a human

Approve

Reject

Audit log

Sealed action, actor, inputs, outcome

Every agent decision passes a permission check and a governance policy; read actions execute directly while sensitive write actions route to human approval, and both are recorded in an audit log.

06 — Tool execution

The model does not touch the database.

  1. 01Model requests a tool
  2. 02Tool registry resolves it
  3. 03Execution guard checks scope
  4. 04Application service runs
  5. 05Domain logic and validation
  6. 06Structured result returns

The model never reaches the database. It can only ask for actions the registry exposes, and each one runs through the same application service a human user would go through.

A model's tool request is resolved through a registry and an execution guard into an application service, so domain logic and validation always run.

07 — Realtime voice

Speaking to the same system.

Voice is an interface, not a separate product. A spoken request enters a realtime session and then follows exactly the same routing, permission and approval path as a typed one.

Microphone

Browser session

Realtime provider

Gemini Live · OpenAI Realtime

JARVIS

Same routing as text

Tool call

Registered ERP action

Governance

Permissions apply identically

Spoken reply

Returned on the live session

Voice input flows through a realtime session into the same orchestrator, agent and tool path as text, and the spoken response returns over the same session.

08 — Provider abstraction

No single vendor in the business logic.

Agentic layer

Agents, tools, governance

Provider abstraction

Routes by capability — reasoning, tool calling, vision, realtime voice, embeddings

Anthropic

Default

OpenAI

Realtime · embeddings

Gemini

Realtime · vision

DeepSeek

Reasoning

A model is a configuration value, not an architectural commitment.

Business logic talks to a provider abstraction, which routes to OpenAI, Gemini, Anthropic or DeepSeek by capability rather than binding to one vendor.

09 — Capability stack

How the layers fit together.

  • Experience

    Chat · Realtime voice · Agent activity view

  • Orchestration

    JARVIS · Intent · Routing · Planning · Delegation

  • Agent

    CRM · Sales · Inventory · Finance · HR · Marketing · Documents

  • Governance

    Permissions · Approvals · Policies · Budgets · Audit

  • Tool

    Registered ERP actions · Execution guard · External research

  • Provider

    Anthropic · OpenAI · Gemini · DeepSeek

  • Platform

    Laravel · React · PostgreSQL · Redis · Queues

The capability stack, from the experience layer down through orchestration, agents, governance, tools and providers to the enterprise platform.

10 — Beyond API integration

What I actually built.

Calling a model API is a few lines. Everything below is the part that took the engineering.

  • Agent orchestration and routing
  • Domain-specific agents with their own tool sets
  • A registry of governed ERP actions
  • Business-context injection per run
  • Provider abstraction across four vendors
  • Permission-aware execution under the caller’s rights
  • Human approval workflows for write effects
  • Data classification, redaction and retention policy
  • Multi-agent delegation with depth limits
  • Autonomous objectives on schedules and events
  • Realtime voice sessions with tool calling
  • Agent activity and run timelines
  • Structured outputs and tool schemas
  • Usage budgets and per-tool rate limits
  • Versioned agent configuration
  • Audit trails and incident records
  • Cancellation and failure handling

Building an AI-powered product or enterprise system?

Let’s design software that does not just respond — it understands context, coordinates tools and agents, and gets work done.

Discuss a projectSee the work