VegaDūta

Glossary

Agentic AI, in plain terms

12 terms you meet when you build AI agents, each defined the way the field uses it — not the way a vendor would like it used — and each linked to its primary source. How VegaDūta relates to a term is kept in a separate, labelled line, so the definition stays a definition.

By the VegaDūta team · Last updated

What is agentic AI?

Also called: agentic artificial intelligence, AI agents

Agentic AI is software in which a large language model does not just produce text but decides what to do next: it plans steps toward a goal, calls tools such as search, databases or APIs, observes the results, and continues until the task is done or it needs a person.

The difference from a chatbot is action. A chatbot answers a question; an agentic system can look up the order, draft the reply, update the record and ask for approval before issuing the refund. Because it acts, it needs controls a chatbot does not: permissions, spending limits, guardrails and a human in the loop for consequential steps.

On VegaDūta

VegaDūta is an agentic AI platform: you describe an agent in one sentence, give it tools and a knowledge base, and deploy it on up to 9 channels, with human approval in front of consequential actions.

AI agents on VegaDūta

What is an AI agent?

Also called: LLM agent, autonomous agent

An AI agent is a program that uses a large language model to choose and carry out actions toward a goal. It combines instructions that define its role, a set of tools it is allowed to call, memory or knowledge it can consult, and a loop that alternates between reasoning and acting.

The reason-then-act loop was formalised in the ReAct paper: the model writes a thought, takes an action, reads the observation, and repeats. Most production agents are a variation on that loop with stricter limits on which tools may run and when.

On VegaDūta

A VegaDūta agent is a role, tools and channels. Agents have 40+ built-in tools, can be given more through MCP, and the same agent can serve WhatsApp, Telegram, email, voice and the web.

How VegaDūta agents work

What is the Model Context Protocol (MCP)?

Also called: MCP, MCP server, MCP client

The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in November 2024, for connecting AI applications to external tools and data. An MCP server exposes tools, resources and prompts in a standard format; an MCP client, such as an AI assistant or an agent platform, discovers and calls them without custom integration code for each one.

MCP is often described as a USB-C port for AI: one connector shape instead of a bespoke integration per tool. Servers can run locally over standard input/output or remotely over HTTP.

On VegaDūta

VegaDūta is both an MCP client and an MCP server. Agents can use MCP servers over STDIO, SSE or streamable HTTP, and VegaDūta exposes 5 tools of its own so an MCP client such as Claude or an IDE can list and call your agents and workflows and search your knowledge base.

MCP on VegaDūta

What is retrieval-augmented generation (RAG)?

Also called: RAG, grounded generation, knowledge base search

Retrieval-augmented generation (RAG) is a technique in which a language model is given relevant passages retrieved from an external document collection at the moment it answers, so the response is grounded in those documents rather than only in what the model memorised during training.

A typical pipeline splits documents into chunks, converts each chunk to a numeric embedding, finds the chunks closest to the question, optionally re-ranks them, and passes the best ones to the model along with the question. RAG reduces fabricated answers and lets a model use private or recent information without retraining.

On VegaDūta

VegaDūta agents answer from documents you upload — PDF, DOCX, HTML, images, audio and video, with OCR for scanned files. Embeddings are computed locally rather than sent to a hosted embeddings API, and a reranker refines results before the model sees them.

RAG on VegaDūta

What are AI guardrails?

Also called: LLM guardrails, content safety filters

AI guardrails are controls that sit outside a language model and check what goes into it and what comes out of it — for example detecting personal data, prompt-injection and jailbreak attempts, toxic language or policy violations — and then block, redact or escalate. They are enforced by the surrounding system rather than requested in the prompt.

On VegaDūta

VegaDūta applies guardrails as a platform layer to every agent: 6 guardrail types covering profanity, jailbreak attempts, personal data, policy violations, toxicity and custom rules, with flagged content sent to a review queue.

Guardrails on VegaDūta

What is human-in-the-loop approval?

Also called: HITL, human oversight, approval gate

Human-in-the-loop approval means an automated system pauses before a consequential action — sending money, deleting data, contacting a customer — and waits for a person to approve or reject it. It keeps a human accountable for decisions the system is not trusted to make alone.

Human oversight is a legal requirement for high-risk AI systems under Article 14 of the EU AI Act, and a recommended control in most AI risk frameworks.

On VegaDūta

VegaDūta has approval as a first-class workflow node and as a gate in front of sensitive agent tool calls: the run pauses until a person approves or rejects, and the decision is written to the audit log.

Approval steps in workflows

What is AI workflow automation?

Also called: agentic workflow, AI workflow

AI workflow automation is the design of a multi-step business process as an explicit graph of steps — triggers, conditions, tool calls, approvals — in which some steps are carried out by a language model or an AI agent. The graph fixes the order and the control points; the model handles the steps that need judgement or language.

A workflow is the more predictable of the two common patterns. In a workflow the path is drawn in advance; in a free-running agent the model picks the path. Many production systems combine them: a workflow for the process, agents for individual steps.

On VegaDūta

VegaDūta has a visual workflow builder with 14 node types — including agent, knowledge, condition, loop, code, parallel and approval — and workflows can be started by a message, a phone call, an email or a webhook.

Workflow automation on VegaDūta

What is the Agent-to-Agent (A2A) protocol?

Also called: A2A, Agent2Agent, agent card

The Agent-to-Agent (A2A) protocol is an open standard that lets AI agents built by different vendors discover each other and exchange tasks. Each agent publishes an agent card — a JSON document, conventionally at /.well-known/agent-card.json — describing what it can do and how to call it.

A2A and MCP are complementary: MCP connects an agent to tools and data, while A2A connects an agent to other agents.

On VegaDūta

VegaDūta implements A2A v1.0 and publishes an agent card at api.vegaduta.ai/.well-known/agent-card.json, so agents on other platforms can discover and call agents built here.

VegaDūta APIs and protocols

What is AG-UI?

Also called: AG-UI protocol

AG-UI is an open, event-based protocol for the connection between an AI agent and the user interface in front of it. It standardises how an agent streams messages, tool calls and state changes to a front end, so any compliant interface can drive any compliant agent.

On VegaDūta

VegaDūta supports AG-UI alongside A2A and MCP, covering the three connections an agent has: to its tools, to other agents, and to a user interface.

VegaDūta APIs and protocols

What does bring your own key (BYOK) mean?

Also called: BYOK, bring your own model, model-agnostic

Bring your own key (BYOK) is an arrangement in which a customer supplies their own API credentials for a language-model provider to a platform that runs on top of it. The customer keeps the billing relationship and the choice of model, and the platform is not a reseller of model usage.

On VegaDūta

VegaDūta accepts your own key for 14 LLM providers, validates it when you add it and stores it encrypted; every agent on the account can then use that provider's models. A platform-hosted model pool is available for accounts that do not bring a key.

LLM providers on VegaDūta

What is multi-tenancy, and what is schema-per-tenant?

Also called: tenant isolation, schema per tenant

Multi-tenancy is an architecture in which one running application serves many customers (tenants) while keeping each tenant's data separate. In the schema-per-tenant model every tenant gets its own database schema — its own set of tables — inside a shared database, which isolates data more strongly than a shared table filtered by a tenant column.

On VegaDūta

VegaDūta isolates each customer in its own PostgreSQL schema, with authentication handled by Keycloak. The architecture and its trade-offs are documented publicly.

Why VegaDūta is built this way

What is LLM-as-a-judge evaluation?

Also called: LLM judge, model-graded evaluation

LLM-as-a-judge is an evaluation method in which one language model scores the output of another against stated criteria such as accuracy, relevance or tone. It makes it practical to grade large volumes of open-ended answers, at the cost of inheriting the judging model's own biases.

On VegaDūta

VegaDūta includes six LLM judges — accuracy, helpfulness, length, relevance, safety and tone — for scoring agent responses.

Observability and quality on VegaDūta

See the terms working together

The sandbox provisions a real tenant — describe an agent in one sentence and test it, no account, no card.