HAVAA is Yukon Labs' AI orchestration platform: one governed AI agent working across Telegram, WhatsApp, web, mobile and email, in any language. It drafts a reply in seconds, checks it against your policy before sending, and escalates to a human when the stakes require it. Every reply is logged with the policy it was checked against and the person who approved it. It runs entirely inside your own perimeter.

What is the difference between an AI agent and a chatbot?

A chatbot answers; an agent acts. A chatbot matches a question to an answer. An agent is given a goal, decides which steps to take, calls tools to do them, and continues until it finishes or hands over. The practical difference is accountability: because an agent changes things, it needs per-user permissions, a boundary on which tools it can reach, and an audit trail.

Can HAVAA run entirely inside our perimeter, with no data leaving the organisation?

Yes — HAVAA runs entirely inside your perimeter, and that is the default for banks and state institutions. The model, orchestration, retrieval index, embedding model and logs all run on infrastructure you control. The detail where most "private AI" claims fail: self-hosting the model while calling a hosted embedding service still transmits every document you index. HAVAA keeps the whole path local, enforced by network egress control rather than a setting.

Which LLMs does HAVAA support — can we bring our own model?

Yes — you can bring your own model. HAVAA treats the model as a swappable component behind a stable interface, so it runs open-weight models you host, models you have licensed, or a hosted API where that is legally available — and can mix them. That also makes it cheaper: most enterprise traffic is simple and routes to a small model, with a larger one reserved for the minority of requests that need it.

What is MCP (Model Context Protocol), and does HAVAA support it?

MCP is the open standard for exposing tools and data sources to AI models, and yes, HAVAA supports it. Its value is portability: a tool built once works with any compatible model. It is now genuine infrastructure — donated by Anthropic to the Linux Foundation in December 2025, backed by AWS, Google, Microsoft and OpenAI, and running at about 97 million SDK downloads a month.

How do you stop an AI agent from taking an action it shouldn't?

You stop an AI agent structurally, not by instructing the model. Three controls: tools are scoped per context, so an agent answering an HR question does not hold a payment tool; every action runs under the requesting user's permissions, never a shared account; and consequential actions need a named human approver. Anything enforced only by prompt wording is not a control.

What hardware do we need to run LLMs on-premise?

Running an LLM on-premise needs less hardware than most expect: one server with one or two high-memory data-centre GPUs serves a real internal deployment. Memory is the constraint: a 70B model needs about 140 GB at full precision but roughly 35 GB at 4-bit. Budget separately for the KV cache, which scales with context length times concurrency.

How well does HAVAA handle Azerbaijani-language content?

Azerbaijani is a first-class language in HAVAA, alongside English, Russian and all other languages, which is treated as a design constraint rather than an afterthought. It has to be: Azerbaijani is low-resource for language models, quality trails English, and the gap widens on banking and legal vocabulary. We test model and quantisation choices against Azerbaijani cases from your own domain before anything ships.

How long does a first HAVAA deployment take?

A first HAVAA deployment takes ten to twelve weeks to a production use case, assuming the deployment posture is settled early. Two weeks to define workload and build an evaluation set in the languages you serve, two to evaluate models, two to stand up the stack, three to build the use case with identity-aware retrieval and audit from the start. The second use case costs a fraction of the first.

Can HAVAA integrate with our existing systems — SAP, 1C, internal APIs?

Yes — HAVAA integrates with SAP, 1C and internal APIs. Each system becomes a tool with a defined schema, validated arguments and its own access rules, so an agent can read from SAP, 1C or a core banking system without any of them being exposed wholesale. The work is less about connectivity than about deciding which operations are read-only and which need a human approval gate.

Is our data used to train any model?

No — your data is never used to train or improve any model, ours or a third party's. It answers your questions and nothing else. On-premise, this is physical rather than contractual: the model runs on your hardware and there is no outbound path. We also prefer retrieval over fine-tuning, so a deletion request can actually be honoured — remove the document and the embedding and it is gone.

If the model produces a wrong answer, is there an audit trail?

Yes — every HAVAA request carries a full audit trail. It records who asked, what was retrieved, which model and version answered, which tools were called, what came back and what it cost. That is what reconstructs a specific interaction months later — the form a regulator's question actually takes — and what an ISO/IEC 42001 auditor asks to see. Log retention and storage location are defined as part of the deployment.

HAVAA is priced per deployment rather than per message, because the cost of an on-premise system is fixed infrastructure plus support, not consumption. The shape depends on deployment posture, the number of channels and use cases in scope, and whether we operate the platform or hand it over. Infrastructure is separate and yours. We scope against your real expected volume during the assessment.

Do we need a data lakehouse before we can deploy AI agents?

No — a data lakehouse is not a prerequisite for AI agents, and treating it as one delays the first deployment by a year for no benefit. What agents need is governed access to the specific data one use case depends on: an authoritative source, defined terms, per-user permissions and lineage good enough to explain an answer. That is a few weeks of catalog work, not a platform migration.

What Is MCP (Model Context Protocol)?

MCP is the open standard for connecting models to tools and data. How it works, what changed when it moved to the Linux Foundation, and the security questions to ask before deploying.

The Model Context Protocol is an open standard for connecting language models to tools and data sources. A capability is implemented once as an MCP server — a database query, an internal API, a document store — and any MCP-compatible model or agent can use it without a bespoke integration.

The problem it solves is unglamorous and expensive. Before a standard existed, every model provider had its own tool-calling format, so an organisation that built twenty integrations against one provider had built twenty integrations it would rewrite when it changed models. Given how often models change, that rewrite was not hypothetical — it was an annual event.

MCP has become the common answer. Launched in November 2024 and donated by Anthropic to the Linux Foundation's Agentic AI Foundation in December 2025 — with AWS, Google, Microsoft, OpenAI, Bloomberg and Cloudflare backing it — it moved from vendor project to open infrastructure in about a year. Adoption followed the governance change: SDK downloads went from roughly 100,000 in the first month to 97 million per month by March 2026, with surveys in 2026 putting around 28% of Fortune 500 companies running MCP servers and roughly 41% of surveyed software organisations in limited or broad production.

How it works

Three roles, and the shape is familiar to anyone who has worked with any client-server protocol.

The host is the application the user interacts with — a chat interface, an IDE, an internal agent platform. It manages the conversation and decides which servers are available in which context.

The client sits inside the host and maintains a connection to each server, handling the protocol mechanics.

The server exposes capabilities. Three kinds: tools, which are actions the model can invoke with validated arguments; resources, which are data the model can read; and prompts, which are reusable templates the host can offer to the user.

The server describes its capabilities in a machine-readable schema. The model sees those descriptions, decides what to call, and the client executes the call and returns the result. The server is ordinary software — it can be written in any language, run anywhere on your network, and enforce whatever authorisation you require.

That last point is the one that matters most in an enterprise, and it is frequently missed: an MCP server is a normal service with normal security responsibilities. It is not a sandbox and the protocol does not grant safety.

Why it matters commercially

Four consequences, in order of how much money they represent.

Model portability. Tools built against MCP survive a model change. Given the rate at which models are released, deprecated and repriced, the ability to swap the model behind a stable tool interface is close to free at design time and very expensive to retrofit.

Reuse across teams. One team builds the core banking query server; six teams use it. Without a standard, those six teams build six connections, pass six security reviews and produce six audit gaps.

A narrower attack surface. Governed correctly, every model access to internal systems flows through a small number of servers, each with its own authorisation and logging. That is a far better position than direct database credentials scattered across application code — which is the alternative, and it is what accumulates when there is no standard.

Vendor negotiation. Portability is leverage. An organisation whose tooling works with any compliant model is in a materially different commercial position from one whose integrations only work with one provider.

The security questions to ask first

MCP makes integration easy, and easy integration is exactly how an organisation ends up with a model that can reach further than anyone intended. Five questions, all of which should be answered before the first server goes into production.

Under whose identity does the server act? The single most important question. If the server holds a service account with broad access, every user who can reach the host has, in effect, everyone's permissions. Identity must propagate from the requesting user through the host to the server, and the server must enforce entitlements per request. This is the same control that matters in every AI orchestration design, and it is the one most often deferred.

Which servers are available in which context? A model answering an HR policy question should not have a payment tool in its registry. Availability must be scoped structurally by context, not restricted by instructions in a prompt.

What can the arguments do? A tool that takes a SQL string is a tool that can run any query. Prefer narrow, typed parameters over free-form inputs, and validate at the server rather than trusting the model to behave.

Who wrote the server? Third-party MCP servers execute code inside your perimeter with whatever credentials you give them. Treat installing one exactly as you would treat installing any other unvetted software with database access — because that is what it is. Public MCP registries are convenient and are not a supply chain you have reviewed.

What is logged? Every tool call, its arguments, the identity it ran under, what came back. Without this an incident is unexplainable and an audit is unanswerable.

MCP in an air-gapped deployment

For banks and state institutions in Azerbaijan, this section is the practical one.

MCP does not require internet access. Servers run on your network, the client connects over your network, and nothing needs to leave the perimeter. That makes it compatible with the on-premise and air-gapped deployments that supervised institutions actually operate — which is not true of every AI integration approach.

Two cautions. First, many published MCP servers are wrappers around external SaaS APIs; those are useless in an air-gapped environment and, worse, may fail in ways that look like configuration problems rather than architectural ones. Audit the server list for outbound calls before you assume the deployment is sealed.

Second, the SDKs and any server you did not write have to enter the perimeter through your normal software supply chain process — reviewed, versioned, and mirrored internally. The protocol being open does not make an arbitrary implementation of it trustworthy.

What to build first

The sequence that avoids the common mistakes.

Start with one read-only server against a system that matters — the data warehouse, the document store — with per-user entitlement enforcement from the first commit. Read-only is the right starting posture because it lets you learn the operational behaviour without the risk profile of writes.

Add one write tool only when the read path is stable, and make the write reversible: create a draft, open a ticket, propose a change rather than commit one.

Keep the tool schemas narrow. Three specific tools with typed parameters are safer and, in practice, more reliable than one general tool that accepts a query string, because the model makes fewer mistakes when the interface constrains it.

Log everything from the first day, at the granularity an auditor would ask for.

And resist the temptation to expose your whole estate because the protocol makes it easy. The value of MCP is that integration is cheap; the risk of MCP is exactly the same sentence.

Key points

MCP is an open standard for exposing tools and data to models, governed by the Linux Foundation since December 2025 rather than by a single vendor.
The commercial value is portability: tools built against it survive model changes, which are frequent and otherwise expensive.
An MCP server is ordinary software with ordinary security responsibilities. The protocol grants no safety by itself.
Identity must propagate from the requesting user to the server, with entitlements enforced per request. A service account flattens permissions across the organisation.
Third-party servers execute inside your perimeter. Treat public registries as an unreviewed supply chain.
It works air-gapped — but audit any server you did not write for outbound calls before assuming the perimeter holds.

HAVAA exposes internal systems to models through MCP with identity propagation, per-context tool scoping and full call-level audit, deployed inside the customer's perimeter. Related reading: what is an AI agent and what is AI orchestration.

What Is MCP (Model Context Protocol) and Why It Matters for Enterprise AI