AI agents

Agents built to run
in production.

The same fabric that runs your deterministic workflows runs your agents: your choice of model, a human approval on any action, and one audit trail across all of it.

Your data, your models, your call

Agents run on the model you choose: any OpenAI-compatible endpoint, including self-hosted models on your own infrastructure, or Anthropic. Knowledge retrieval indexes into your own Postgres/pgvector database, not a third-party vector store. And with On-Prem Workers, flows run inside your network over an outbound-only connection, so the business data those flows handle is processed where it already lives.

  • Bring your own LLM: OpenAI-compatible endpoints, self-hosted models, or Anthropic
  • RAG indexes into your own Postgres/pgvector, with embeddings on models you control
  • On-Prem Workers process business data inside your network for on-prem flows
  • Cloud-run step data is sealed with AES-256-GCM encryption at rest

Run agents where your systems are

Fully managed cloud workers handle cloud-to-cloud work. On-Prem Workers reach the databases, ERPs, and internal apps you never expose to the internet, connecting outbound only, with no inbound ports to open. The same agent definition runs on either.

  • Managed cloud workers for cloud-to-cloud workloads
  • On-Prem Workers for systems inside your network, outbound-only connection
  • Cert-bound worker enrollment, no inbound firewall holes

Approval is a first-class step, not a bolt-on

Autonomy is a dial, not a switch. Any agent action can require a human decision before it executes. Reviewers see the reasoning and the proposed action, not just a yes/no button, and every decision lands in a task inbox with SLA timers and escalation.

  • Require approval on any action before it executes
  • Reviewers see the agent reasoning and the proposed action
  • Approvals live in a task inbox with SLA timers, escalation, and reassignment
  • Every decision, human or agent, lands on the same audit trail

Give any agent a face

An agent only helps the people who can reach it. Neblex agents meet people in the channels they already use, and the platform's form and app builders put real interfaces on top, with the same auth and audit trail as everything else.

  • Embeddable web chat, Slack, and Microsoft Teams channels
  • Voice conversations for hands-free interaction
  • Forms and app buttons start governed flows that include agent steps
  • Durable agent memory carries context across conversations
Built for every builder

Three ways in, one governance model

Not everyone who needs an agent writes code, and not everyone who writes code wants a canvas. Every path is governed the same way.

Line of business

Plain English

Describe what the agent should do and Neblex drafts the tools, decision logic, and approval checkpoints. Refine by describing the change.

  • Parses multi-step, conditional instructions
  • Proposes connectors and checkpoints
  • No prompt engineering required to start

Power users & analysts

Visual builder

Drag-and-drop building for the person who knows the process best, with the logic laid out on a canvas instead of hidden behind a prompt.

  • Visual flow and agent building
  • 236 connectors ready to drop in
  • Test runs before anything goes live

Developers & engineers

Your AI IDE, via MCP

Neblex ships an MCP server with OAuth 2.1, so Claude Code, Codex, Cursor, and other AI-assisted tools can build, inspect, and operate flows and agents programmatically.

  • MCP server with OAuth 2.1 + PKCE
  • Build, validate, and run from your IDE
  • Export flows as signed, portable definitions

Governed the same, no matter who builds

  • Role-based access controls who can build and run agents
  • Environments with promotion approvals gate the path to production
  • A tamper-evident, hash-chained audit trail records every action
  • SSO (SAML/OIDC), SCIM provisioning, and 2FA govern platform access
Runtime

What the runtime does for your agents

Agents inherit the same engine that runs deterministic flows, and its properties are architectural, not aspirational.

Warm connections

Database and API connections are pooled and reused instead of re-established on every step.

Parallel step execution

Independent steps fan out and run concurrently with bounded concurrency, instead of waiting in line.

Horizontally scalable workers

Execution capacity scales out across workers that lease work from a shared queue.

Durable pause and resume

A run waiting on human approval parks durably and resumes exactly where it stopped, no cold restart.

Execution near your data

On-Prem Workers run flows next to the systems they touch, cutting round trips out of your network.

Event-sourced replay

Every run is an append-only record. Replay a failed run from the exact step that broke.

See an agent running against your systems

Bring a real workflow to the beta and build it against your own stack, not a sandbox.