Skip to content
Expertise
Agent Harness & Deployment

Agent harness and deployment.

Every tool call inside a boundary you set.

An agent is a model you gave tools, credentials, and permission to act. I build the safety rails that decide what it can touch.

See the case studies
A small glowing mechanism inside a steel cage, a spotlight casting barred shadows across a concrete floor

What an agent harness is

An agent harness is the set of controls around software that picks its own next move. Six parts, and skipping one turns a convincing demo into an incident review.

Tool access boundaries

An agent is only as dangerous as its tools. It gets them through a strict gateway, like an MCP server.

Sandboxing

The agent runs code and writes files inside a container it cannot leave. Destructive changes hit a staging copy first.

Permission models

Each agent sees only what its user's role allows. Writes above your limit stop and wait for a named human.

Eval gates

A prompt change ships like code, through an eval gate that tests it against a golden dataset of known answers.

Observability and audit

I trace every prompt, tool call and token to its session. Months later, the trace, not the engineer, explains why.

Deployment target

Managed APIs, your own servers, or fully air-gapped with no outside connection. Your constraints decide which, before the build starts.

Each gateway sits in front of your database, internal APIs or document store, with auth, rate limits and tested capabilities. Access follows each user's role, so a support agent and a finance agent reading the same documents get different answers by design.

Where the harness runs

I design the boundary before picking where the agent runs, so you can switch models later. The harness stays the same on all three targets.

Managed model APIs

OpenAI, Anthropic or Google, when speed and capability matter more than where data sits. Switching provider is a config change.

Your own infrastructure or private cloud

Open-weight models like Llama 3, Mistral and Qwen, on hardware you control. Prompts, documents and embeddings never leave your network.

Air-gapped

No outbound traffic, for when a regulator or defence contract requires it. Models, data and hardware stay inside your jurisdiction.

Where the harness earns its keep

Four situations where the permission model does more work than the model choice.

Regulated document work

Agents review contracts and check compliance without files leaving your network. Role-based redaction hides one client's files from another.

Clinical and patient-facing assistants

Records analysis, clinical notes and patient queries under HIPAA-scoped access, with no cloud exposure. Agents read widely but write narrowly.

Financial operations

Fraud review, risk and reporting agents working on your own financial data. Costs capped per tenant, and every decision traced.

Plant and supply chain systems

Predictive maintenance, supply chain and quality control agents on the factory network, where cloud calls are unreliable or banned.

Stack I work in

LangChainCrewAILangGraphOpenAI APIMCP ProtocolOllamavLLMLlama 3MistralQwenChromaDBPineconeWeaviateSupabase pgvectorDockerKubernetesFastAPIPython

Running agents in production, answered

What to settle before an agent touches production.

  • An agent harness is the control layer around an AI agent. It decides what the agent can reach and what it may do. Its six parts start with a typed tool surface, an execution sandbox and an identity-based permission model. The rest are eval gates that decide what ships, tracing and audit on every call, and a deployment target. The name comes from the test harness in software engineering, the scaffolding that runs code under controlled conditions and reports whether it passed. Without one, an agent is a language model holding production credentials with nobody supervising it.

  • A framework runs the agent's loop, and a harness controls everything around that loop in production. The loop plans, calls a tool, reads the result and decides what to do next. The harness decides which tools exist, what runs in a sandbox, who approves a write, which changes clear an eval gate and what gets traced. Pooya Golchian builds with LangChain, LangGraph and CrewAI, then adds the layer those frameworks deliberately leave to you. No framework can know your permission model, your compliance boundary, or which write action needs a human on it.

  • Pooya Golchian combines a typed tool surface, a sandbox, and human approval on any write above a set threshold. A capability nobody granted the agent does not exist for it. Execution, file writes and network calls run in a sandbox with a blast radius fixed before launch. Destructive operations hit a staging copy first. A named human gives each approval, and the log records who. Eval gates catch the slower failure, a prompt or model change that degrades output without throwing an error. They run a golden dataset and LLM-as-judge scoring before anything reaches release.

  • Yes. Pooya Golchian runs the data residency review first, before anyone picks a model. It covers PDPL and DIFC for UAE work, GDPR for European data, and HIPAA and SOC 2 readiness where the sector demands it. If the review rules out a managed API, the model weights, vector store and inference hardware all sit inside your legal jurisdiction. Identity, role-based access and the audit log feed your SIEM, your security monitoring system. He also deploys fully air-gapped systems, with no outbound connection at all.