AI agents for the judgment calls a deterministic workflow cannot handle

"If this, then that" automation breaks down the moment a step needs judgment: classifying an ambiguous support ticket, deciding whether a refund request looks legitimate, drafting a reply that actually fits the situation.

Hand that judgment to an AI tool that sits outside your integration platform and you inherit a second system, with its own permissions model, its own audit trail, and its own blind spot for what the agent is actually allowed to touch.

AI agents in Neblex Integration Fabric are reasoning-based automations that handle the steps a fixed rule cannot, and they run on the same platform, the same connectors, and the same audit trail as deterministic flows. There is no separate agent framework with its own governance.

Build an agent in its own builder: pick its model and connection, write its instructions, grant it tools, and decide which tool calls need a person's approval. Matt, the Neblex AI Assistant, guides you through it, and MCP can create and change agents programmatically. An agent never invents a connector or an action that does not exist in your environment.

Any agent action can pause for human approval before it executes. Every action, agent or flow, lands on the same tamper-evident audit trail, so "what did the AI actually do" is never a separate question from "what did the flow do".

Agents are built in the agent builder, with Matt, the Neblex AI Assistant, guiding you, or over MCP, which can create, update, publish, and run agents with consent scopes for operating, authoring, and publishing.

• Agent builder. Choose the model and connection, write the instructions, grant tools, set which tools need approval, and configure channels and the hosted chat.
• Matt. Ask how to express a task or a guard rail and Matt explains and drafts; it runs on the platform's builder model by default, or on a model you connect for the building experience only.
• MCP. Create and change agents programmatically, so an external client or agent can build on Neblex directly.

The model Matt uses is separate from the model a deployed agent uses. A running agent, its tools, and its knowledge store always use your own provider connections and keys, configured under AI Agents and Connections. In the product's own words: this setting never supplies a model or credential to deployed AI Agents, Agent tools, RAG, Apps, or Flows.

• Build in the agent builder with Matt, the Neblex AI Assistant, guiding you, or over MCP
• Human-in-the-loop per tool: a tool marked for confirmation is proposed by the model, recorded as a pending action, and runs only after a person approves
• Agents only use connectors and actions that exist in your environment, nothing is invented
• Same governance and tamper-evident audit trail as deterministic flows, no separate system to monitor
• Change an agent's instructions, tools, or model and publish a new version; hosted chat and embeds always serve the published version
• Nine tool kinds: Operation, AI Model, Database, Flow, Sub-Agent, Knowledge Search, Long-Term Memory, Remote Agent (A2A), and Browser (Web RPA)
• Reachable from Slack, Microsoft Teams, and native voice, plus a brandable hosted chat UI with a one-line iframe embed
• Callable as a single step inside a deterministic workflow, for the judgment part only
• An AI Model tool lets the agent consult a second, separately connected model as a reviewer, and a flow that calls the agent can check its result with an Assert Data Quality step before anything downstream runs

Every tool runs against a connection you own, at the access level you set. The agent cannot reach past it.

• Operation. One operation from any connected app or database: look up an order, post a message, run a single query.
• Database. Point the agent at a database connection and it writes and runs its own statements, including schemas, joins, and procedures. The credential is the boundary: attach a least-privilege database user, because that, not the text of the query, is what limits the agent.
• Knowledge Search. Ground answers in your own documents. The agent embeds the question and returns the closest passages from a vector store you own, with nothing copied off your database. A guided installer stands the store up on Postgres you own, with pgvector.
• Long-Term Memory. Remember durable facts about each user across conversations, such as preferences and account details, in a store you own. Memory is scoped to the caller's verified identity, never the model's choice, deduplicated, capped per user with the oldest evicted first, and expiring.
• Flow. Run one of your deterministic flows end to end, with its retries, error handling, and audit trail included.
• Sub-Agent. Delegate to another Neblex agent that has its own instructions and tools.
• Remote Agent (A2A). Hand a task to another company's agent over the open Agent2Agent protocol, at an endpoint you fix in the builder, and use its answer.
• Browser (Web RPA). Operate a real website that has no API, sign-in steps included, when there is no other way in. Navigation is clamped to the sites you list, an empty list means the tool will not navigate at all, and every call has an action cap.
• AI Model. Consult OpenAI, Anthropic, or another model through a separate connection and API key on the same agent, for example as a specialist reviewer the primary model asks for a second opinion before it acts.

Knowledge search needs a vector store. The Agent Knowledge Installer is a guided wizard that stands one up on Postgres you own, rather than copying your documents into a store you cannot see. It runs in about 5 to 15 minutes across five steps: connections, host and network, knowledge, review, and install.

• Creates or selects the embeddings connection and the Postgres credentials, and tests the route to the host
• Installs pgvector on a managed database, an existing server, or a clean supported Linux host
• Runs the initial indexing, then turns on continuous synchronization so the store stays current
• Reaches a private host over an online On-Prem Worker; public endpoints go through the cloud runner
• Finishes only when the knowledge tool is verified ready for the agent to call
• Advanced manual configuration is there for teams that want to set each piece themselves

People reach an agent from Slack, Microsoft Teams, or voice over a phone call or the browser. The voice channel is native: the call transport, the speech-to-text (STT) stage, and the text-to-speech (TTS) stage are each chosen independently, and the call is routed straight through the agent's conversation rather than handed off to a separate product. A deterministic workflow can call the agent as a step as well, so one agent serves people and automated processes alike.

Loop and cost controls sit on every agent: Max turns, Temperature, and Token budget per run, with platform defaults an author can only tighten. Workspace-level caps on agents, runs, and tokens per month sit above them.

Approval works per tool. Mark a tool as requiring confirmation and the model may propose the call, but the platform records it as a pending action and does not run it until a person approves. To check what an agent produces, a flow that calls the agent can run an Assert Data Quality step on the result before anything downstream happens.

Every agent also ships a hosted chat UI, so there is no front end to build. You set the greeting, the input placeholder, and up to four suggested questions in the same place you build the agent, and set access to public (anyone with the URL) or private.

Share it as a link, or drop it into your own site with the one-line iframe embed. Both the link and the embed always serve the published version of the agent, never your working draft.

A real agent teams build on day one, with the actual step-level detail.

Ambiguous tickets classified and routed, with a checkpoint on refunds

Inbound tickets that do not match a routing rule go to an agent. It reads the ticket, assigns a category and priority, drafts a first reply, and routes the ticket. Anything that proposes a refund waits for a human.

1. 1Trigger: a new Zendesk ticket with no matching macro or routing rule wakes the agent.
2. 2Read: the agent pulls the ticket body, the customer record, and the last 90 days of order history from the connectors it is granted.
3. 3Classify: it sets category, priority, and a short rationale written back to the ticket.
4. 4Draft: it writes a first-response comment as an internal note, not sent to the customer yet.
5. 5Checkpoint: if the proposed action includes a refund, the run pauses for team-lead approval with the rationale attached.
6. 6Act: on approval, or when no refund is involved, the agent posts the reply and assigns the ticket to the mapped queue.
7. 7Log: the classification, the draft, the approval, and the final action all land on the one audit trail.