Agent harness and deployment.
Every tool call inside a boundary you set.
A model on its own is a text generator. An agent is that model plus tools, credentials, and permission to act, which is exactly where the engineering starts and exactly where most pilots quietly stall. I build the layer around it. The one that decides which tools the agent can reach at all, what runs inside a sandbox instead of against your production database, which changes clear an eval gate before release, and where the whole thing runs when your compliance team has already made that decision for you.
What an agent harness actually is
Harness is a word borrowed from testing. A test harness is the scaffolding that runs code under controlled conditions and reports back whether it passed. An agent harness does the same job for a system that writes its own next move. Six parts make it up, and skipping any one of them is how a convincing demo becomes an incident review.
Tool access boundaries
An agent is only as dangerous as the tools you hand it. Every capability arrives through an explicit, typed surface rather than an open shell, usually a Model Context Protocol server fronting your database, your internal APIs, and your document store with auth, rate limits, and a tested capability contract. Anything not on that surface does not exist as far as the agent is concerned.
Sandboxing
Code execution, file writes, and network calls run inside a container the agent cannot step out of, with the blast radius sized before anything ships. Destructive operations land in a staging copy first. Production stays a system the agent reads from far more often than it writes to.
Permission models
Identity, role-based access, and per-role redaction decide what each agent sees on behalf of each user, so a support agent and a finance agent working the same corpus return different answers by design. Write actions above a threshold you define stop and wait for a named human, and every approval is recorded with the identity that granted it.
Eval gates
A prompt change is a code change and it ships through a gate. Golden datasets, LLM-as-judge scoring with calibration, and regression suites run before release, so a model swap or a reworded system prompt cannot quietly degrade output that nobody is watching. Passing the gate is the release criterion.
Observability and audit
Every prompt, every tool call, every token, traced and linked back to the session that caused it and stored where compliance can find it later. Cost guardrails and rate limits sit on the same telemetry, applied per tenant or per role. When someone asks in March why the agent did that in January, the trace answers instead of the engineer.
Deployment target
The harness runs where your constraints put it. Managed APIs when capability and latency outrank residency, open-weight models served through vLLM or Ollama when the data cannot leave the building, and fully air-gapped when a regulator has already settled the argument. That is a week-one decision, not the identity of the work.
Where the harness runs
The boundary gets designed before the runtime gets chosen, which is what keeps the model decision reversible. Three targets, and the harness is the same shape across all three.
Managed model APIs
OpenAI, Anthropic, and Google, picked when capability and latency matter more than where the bytes sit. Only the inference endpoint changes. The tool surface, the permission model, the evals, and the traces carry across untouched, so swapping a provider is a configuration change rather than a rebuild.
Your own infrastructure or private cloud
Open-weight models including Llama 3, Mistral, and Qwen, served through vLLM or Ollama on hardware you control, with the embedding model and the vector store sitting alongside them. Prompts, documents, and embeddings never cross your network boundary or reach a third-party API.
Air-gapped
No egress at all, for environments where a regulator or a defence contract has already made the call. Model weights, vector store, and inference hardware all sit inside your legal jurisdiction, with identity, role-based access, and the audit log wired into your SIEM.
The residency question gets answered in week one, before anyone picks a model. That review covers PDPL and DIFC for UAE work, GDPR wherever European data is in scope, and HIPAA and SOC 2 readiness where the sector demands it. The answer sets the deployment target and nothing else. It does not change the harness, which is the whole point of building the boundary first.
Where the harness earns its keep
Four situations where the permission model does more work than the model choice.
Regulated document work
Contract review, clause extraction, and compliance monitoring running as agent tasks against a corpus that never leaves your network. Per-role redaction does the hard part here, because an agent reading matter files for one client must never surface them to another.
Clinical and patient-facing assistants
Records analysis, clinical note drafting, and patient query handling under HIPAA-scoped access, deployed without cloud exposure. Read access stays broad and write access stays narrow, which is the correct default the moment a wrong answer becomes part of a record.
Financial operations
Fraud review, risk assessment, and automated reporting agents grounded in proprietary financial data, with cost guardrails per tenant and a trace on every decision the model contributed to.
Plant and supply chain systems
Predictive maintenance, supply chain, and quality control agents running locally on factory networks, where a round trip to a cloud API is neither reliable enough nor permitted.
Technology Stack
Running agents in production, answered
What a harness is, how it differs from a framework, what stops an agent doing damage, where it can legally run, and what the work costs.
An agent harness is the runtime layer around an AI agent that decides what it can reach and what it is allowed to do. Six parts make it up. A typed tool surface, a sandbox for execution, a permission model tied to identity, 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 gives you the orchestration primitives, the loop that plans, calls a tool, reads the result, and decides what to do next. A harness is everything that surrounds that loop in production. Which tools exist at all, what runs inside a sandbox, who approves a write, which changes clear an eval gate, and what gets traced. Pooya Golchian builds with LangChain, LangGraph, and CrewAI and then adds the layer those frameworks deliberately leave to you, because no framework can know your permission model, your compliance boundary, or which write action needs a human on it.
Three controls, applied together. The tool surface is explicit and typed, so a capability the agent was never granted simply does not exist for it. Execution, file writes, and network calls run inside a sandbox with a blast radius decided before launch, and destructive operations hit a staging copy first. Write actions above a defined threshold stop and wait for a named human, and every approval is recorded with the identity that granted it. Eval gates catch the slower failure, the prompt or model change that degrades output without ever throwing an error, by running a golden dataset and LLM-as-judge scoring before anything reaches release.
Yes. Pooya Golchian works from Dubai and deploys self-hosted, open-weight models like Llama, Mistral, and Qwen onto client-owned infrastructure across the UAE, served through vLLM or Ollama so prompts, documents, and embeddings never cross your network boundary or reach a third-party API. He has shipped production systems for regulated fintech, including a payments platform running $10M+ monthly at 99.99% uptime. Engagements are hands-on inside your codebase.
Yes, and the residency review happens in week one of an agent harness engagement, before anyone picks a model. That review covers PDPL and DIFC for UAE work, GDPR where European data is in scope, and HIPAA and SOC 2 readiness where the sector demands it. Where the answer rules out a managed API, the model weights, the vector store, and the inference hardware all sit inside your legal jurisdiction, with identity, role-based access, and the audit log wired into your SIEM. Fully air-gapped deployment is supported for environments with no permitted egress at all.
Agent harness and deployment engagements with Pooya Golchian start at $15,000. That fixed-scope floor covers one production use case, delivered over four weeks, with the tool surface, the permission model, an eval suite with a golden dataset, an audit log, an architecture document and runbook, and 30 days of post-launch support all included. Most engagements run four to six weeks end to end, and larger rollouts move to fixed scope per phase. Work starts with a discovery call or a written brief through the contact form on pooyagolchian.com.
Engagement
Let's build the boundary first.
Every agent needs a different perimeter, and the constraints usually arrive from your compliance team rather than your roadmap. Book a discovery call to size the work, or send a brief in writing.
Agent harness engagements start at $15k.
Most run 4 to 6 weeks, one production use case, on the deployment target your constraints allow. Larger rollouts go fixed-scope per phase.