The iChat engine, sold on its own

iHarness is the engine inside iChat, IOTA’s AI coding assistant for regulated, air-gapped organisations. It is now sold on its own. It sits between any chat tool or IDE and the models you host yourself, and makes every request safer, cheaper and more accurate. For teams that already have chat tools and IDE assistants, each tool needs one change: where it sends its requests.

How it is built

iHarness is a single gateway, delivered as one package, that runs inside your network. Your existing AI tools point at iHarness instead of straight at a model, and every request passes through five stages.

• Admit — access key, roles and model access, rate limits, token budgets per key and the offline licence.

• Shape — secrets and personal data masked; organisation instructions, memory, tool guidance, skills, per-model tuning and think-first reasoning added.

• Run — pass the request through to the model, or run the server-side agent with plugins, approved scripts, helper agents, metrics and logs.

• Check — broken answers and tool calls repaired; every tool call tested against blocked tools, protected files, destructive commands and your own policy rules.

• Record — every request, tool call and denial written to the audit trail, with usage metrics.

Unattended work runs through the same pipeline. A loop engine starts runs on a schedule or on verified repository events and holds them to the same checks. The architecture diagram is in the product deck, available on request below.

Agents that check their own work

Most AI assistants answer once and stop. iHarness can now run loops: agent runs that start without anyone prompting them and keep working until the result passes your checks.

• Start on their own — loops start on a schedule (nightly, hourly, weekdays at nine) or when something happens in your code repositories, such as a push or a new change request. Every trigger is verified before a loop runs.

• Stop only when the work is right — a loop finishes when your own lint and test checks pass, when its answer matches what you expect, or when a separate reviewer agent checks the work and approves it.

• Learn between attempts — each new attempt is told exactly which check failed and why.

• Stay within budget — each loop has a limit on tokens, time and attempts. When it cannot finish within them, it hands over to a person in your team chat or ticketing tools. That person can add guidance and resume it in one step.

• Leave a record — every run keeps a readable progress and decision log, and every step is in the audit trail.

• Same guardrails as people — loops act under a named identity with its own roles. They get the same masking of sensitive data, tool-call checks, policy decisions and audit as any user.

Loops fix things rather than report them. A loop can work on a private copy of your repository, with your application running from it, and check the application the way a person would.

• Using the application — it sends real requests to the running application.

• Reading its logs — it reads the application’s own log output.

• Opening it in a browser — it loads pages the way a user would and sees errors, crashes and failed requests. Nothing extra needs to be installed, so this works air-gapped.

• Watching production — it checks your existing monitoring for error rates and latency.

When every check passes, the changes are packaged for review. They are proposed back to your repository only after your policy rules or a named person approve. The original code is never touched before that.

What a loop is worth is measured per loop: success rate, attempts per success, tokens per success, median run time and changes delivered. The figures are available in the terminal, through the API and on your existing dashboards. Any access key can also carry a daily or monthly token budget, so an IDE’s agent mode or an automated pipeline cannot run away with your GPU time.

Think-first answers from the models you already run

The best coding assistants do not jump straight to code. They work out what is being asked, look at what the change touches, plan, and check the plan before they write a line. iHarness brings that discipline to the models you host yourself, with no retraining and no new hardware.

• Understands before it answers — every request starts with the assistant restating the task and naming any assumption it has to make.

• Plans the change — it maps the files and functions involved and sets out the steps. For a bug, it lists the likely causes and how to tell them apart.

• Thinks about what could break — edge cases, error handling, security and the effect on existing callers and tests are part of the plan.

• Checks its own plan against the request before it answers.

• Clean, consistent answers — the result comes first, code is clearly marked, and every answer ends with how to verify the change. The working-out stays out of the answer, the saved history and your automated checks.

• Reasoning on request — tools that can show the reasoning get it separately. Tools that cannot simply get the clean answer.

• You decide where it applies — switch it on for the whole organisation or only for chosen models. Strict machine-readable answers are left untouched.

• Fully accounted for — reasoning stays inside your network, counts against token budgets and is recorded in the audit trail.

The improvement comes from how iHarness guides the model, not from training on another vendor’s output, so there are no new provenance or licensing questions for your compliance teams.

Works with the tools you already use

• Speaks the industry-standard AI interfaces, so IDE assistants, chat portals, in-house applications and developer toolkits connect without code changes.

• Works with your model platform, whether you host models yourself, run them on a private cloud service, or use the model server we include.

• One package for fully air-gapped installs. Licensing works offline, and a gateway-only edition needs no single sign-on set-up.

• IT can push the settings centrally through device management, the developer image or environment variables, so developers do nothing.

Makes models give better answers

• Tuning per model — guidance, settings and context limits that suit each model.

• Organisation-wide instructions and coding standards, added to every request.

• Simple model names, such as “fast” and “smart”, that point to the right deployment.

• Malformed structured answers and tool requests are caught and re-asked before your tool sees them.

• Long conversations are summarised automatically by a smaller, cheaper model.

• Built-in workflows for review, QA, planning and more work in any connected tool.

Keeps you in control

• Secrets and personal data are masked before they reach the model.

• Every action the model asks for is checked before it reaches the IDE: blocked tools, protected files, destructive commands and your own policy rules.

• Per-user access keys, model access by role, rate limits and token budgets.

• A full audit trail that feeds the security and monitoring platforms you already run.

Extends what the model can do

• Plugins — connect your own systems, such as tickets, databases and internal APIs, through an open plugin standard, locally or across your network.

• Approved scripts — your administrators choose which commands the model may run, such as linting, build status or opening a ticket. Nothing runs outside that list.

• Helper agents — the agent can hand self-contained sub-tasks to helpers that start fresh, several at a time.

• Memory — tell the assistant something once, such as how you deploy, and it remembers it in every later conversation. Notes are masked and kept per user.

• Tool guidance — write your organisation’s rules for when and how each tool is used, and they go to the model with every request.

• Observability — the agent can check your metrics and logs to see error rates and latency for itself.

Deployment and integration

• Docker host or VM with docker compose — the fastest route to a pilot

• Kubernetes or OpenShift — Deployment, Service and Ingress or Route with your TLS certificate, two or more replicas for high availability

• Air-gapped networks — a signed offline bundle loaded into your internal registry; no internet access at any point

• Models — the model server we include, your own model servers or private cloud models through a standard interface; an existing gateway route such as LiteLLM, Azure API Management or Kong also works

• Secrets — gateway key and session secret from Kubernetes Secrets, HashiCorp Vault or Azure Key Vault

• Audit and monitoring — Splunk, Elastic, OpenTelemetry, Dynatrace or Sentry, or a rotated, optionally encrypted file, with health and metrics endpoints

• Sizing — the gateway performs no inference of its own, so it is light; capacity follows concurrent users, not tokens

Rollout

• Install, about one week — gateway running in a non-production environment, connected to models and SIEM, smoke tests passed

• Pilot, two to four weeks — one team of 10 to 30 developers using it daily; profiles, policies and alerts tuned; quality and latency measured

• Expand — production with high availability, keys issued per team, client settings pushed centrally, first loops scheduled

• Enforce — direct access to model endpoints closed, so every AI call is governed and audited

Each phase can be reversed by pointing tools back at the gateway.

Built for regulated environments

Everything runs inside your network. There are no calls home, licences are checked offline, and every request, tool call and loop run is audited. iHarness follows current industry and research best practice for building safe, reliable AI agents.

Status

iHarness is pilot-ready. It installs in about a week and a first team can be using it daily within the month, inside your perimeter, with nothing calling out.

Request access: tell us about your environment through the form on our home page and our team will connect with you. The product deck, with the full architecture, is available on request below.