Nobody cares that you have AI

Every data integration vendor shipped AI in the last eighteen months. A chat panel that answers documentation questions. A button that guesses a mapping. A "generate SQL" box wired to a model that has never seen your database.

Buyers worked this out fast. The question that decides anything is whether the agent can do the job, inside the platform, with your permissions, on your data. Most cannot get past the first clause.

The test

Ask a vendor's agent to build a working pipeline from one sentence. Not describe one. Build it, save it, run it, show you the result.

That request exposes everything. The agent has to read your existing connections to know what a source is. It has to introspect schemas to produce a mapping. It has to create artifacts rather than paste YAML into a chat window. It has to run as you, so it cannot touch what you cannot touch. An agent bolted onto a documentation index fails at step one.

What we built

Simba, our AI agent, builds artifacts. As of 9.7.11 it creates and modifies every artifact type, works inside Composer, our visual flow builder, and standard flows, and is tenant-aware from the CLI. You describe the work, review what it produced, save it.

Mapping happens by conversation. Open Simba from any mapping editor and say what you want: exclude the audit columns, build a nested mapping with orders as an array. Iterate, then tell it to apply. The proposal lands in the real editor as a draft, not in a transcript you retype.

Code gets written with help that knows your environment. Autocomplete suggests identifiers based on the language, the cursor position, the fields available at that point, symbols you declared, functions and macros you are authorized to call, and the schema of the live database connection.

Other agents can drive the platform. Etlworks exposes its tools through an MCP server at POST /rest/v1/ai-agent/mcp. JSON-RPC 2.0, bearer auth with your existing API key, the same tool catalog Simba uses internally. Claude Desktop, Claude Code, Cursor, and Windsurf all connect to it. There is a REST agent API for your own code and a subagent pattern for LangChain, CrewAI, and AutoGen.

Why a general coding agent cannot do this

Claude and Codex are excellent. Point either at your pipeline and you get good SQL, a sensible script, and confident nonsense about your environment.

They do not know which of your forty connections points at production Postgres. They cannot read a schema behind your VPN. They have no access to the run history showing that the flow failed last week for an unrelated reason. That is a data access problem, and model capability does not solve it from the outside.

The interesting engineering in agentic data integration is the toolchain and the permission model. The model is the commodity part.

The part that makes it usable at work

An agent that builds anything is a liability with no governance, so AI is a first-class channel in the permission system rather than an exception.

The agent acts as the calling user and cannot exceed that user's authority. The same permissions apply through the UI, REST, the CLI, agentic AI, and MCP. A user denied Run/Use on flows cannot run one by asking the agent politely. Agentic AI switches off per user, per group, or per tenant, where it becomes a ceiling nothing overrides.

Cost is visible. The Insights dashboard tracks token usage and cost per user, per session, and per tenant, and the same figures come out of the CLI and the API. Bring your own OpenAI key and you pay OpenAI directly, with no markup from us.

What we skipped

We did not put a chat box on every screen and call it AI-native. Scattered features produce six half-integrations and a support burden. One tool registry, one permission model, one place to look when something breaks.

Run the test at the top of this post on us. The MCP setup guide takes five minutes.