AI Agents Over Your Data: Three Working Examples

The word "agent" got worn down before it had a chance to mean anything. It's used for a chat-bot with a system prompt, for autocomplete, and for a button that says "ask AI". So let's start with a boundary.

An agent is not a chat-bot

A chat-bot responds to messages. Its world is the current dialog window. Give it data in a message — it works with it; don't — it reasons in the abstract.

An agent knows context and takes actions. It has persistent access to a data source and tools to change that source. The difference isn't the model — same model. The difference is that the agent has hands and a memory of the world's state beyond the dialog.

And here is where almost all agentic setups stumble on one thing: context. For an agent to be an agent, it needs somewhere to read current data and somewhere to write results. Without that, it remains an articulate chat-bot.

Korfix MCP: the agent gets hands

Korfix stores data in catalogs — typed, linked tables — and serves them via MCP. For an agent this means two things:

• Read. The agent sees the catalog directly: fields, types, values, relations. Not a snapshot frozen at copy-paste time, but the current state.
• Write. With a write token the agent creates and updates records. db_insert, db_update — these are its tools, not your manual operations after its "advice".

One token from settings — and any MCP-compatible client transforms from a conversation partner into an agent with both context and hands. Three examples below show what that unlocks.

Example 1. Claude Desktop analyzes expenses for the month

You have a Transactions catalog — amount, category, wallet, date. Connect it to Claude Desktop via MCP and at the end of the month write:

Analyze my spending for May. Where did I go outside my usual pattern, and where can I realistically save?

Claude doesn't ask for an export. It reads Transactions itself, groups by category, compares with previous months, finds outliers, responds with a breakdown. This isn't "calculate from the table I pasted" — it's an agent working with live data on your request.

Add write permission to the token — and you can go further: "log a transaction: $50, groceries, cash" — Claude creates the record itself.

Example 2. Cursor writes code from the catalog schema

You're developing an app on top of Korfix. Cursor is connected to the platform via MCP — and sees not an abstract "database" but specific catalogs with their schemas.

Make a form for creating an application record for the applications catalog.

Cursor reads the catalog schema: which fields exist, which are required, where there's a select and what values it has, where there's a relation and to what. And generates a form that matches the real structure, not an imagined one. Fewer "oh, that field doesn't exist" iterations — the agent checks against the source, not guesses.

Example 3. n8n agent creates a task from an event

An agent doesn't have to live in an IDE. In n8n the AI Agent node with Korfix connected via MCP reacts to events.

An email arrives, a message comes to a bot, a webhook fires from a form. The agent in the workflow reads the event, decides what it is — a request, an inquiry, a lead — and creates a record in the right catalog, filling fields by meaning. Not a rigid "field A → field B" mapping, but an agent that understands the incoming data and places it correctly.

This runs unattended. Event arrives — task appears.

Security: give the agent a key, not a keyring

An agent with data access is about trust, and it should be treated as such. In Korfix there are two mechanisms for this.

Tokens with limited permissions. A token is created in the panel (/db/api) and carries exactly the permissions you gave it: specific catalogs, specific methods. The agent that analyzes expenses needs one catalog and read-only — give it a token for one catalog and read-only. The n8n agent that creates applications — access to Applications on write and nothing else. Different agents, different tokens, and if one is compromised, you revoke it without touching the others.

Audit log. Requests to data are recorded. You can see which token read what and wrote what. The agent doesn't work in a black box — it leaves a trail you can follow.

The principle is simple: give the agent the minimum key for the specific job, not the whole keyring. Then "giving the agent hands" is a managed risk, not a blind bet.

What's next: agent to agent

Right now an agent works with your data. The next step the platform is moving toward is cross-account interaction.

When every user has their own catalogs and their own agents, a new scenario emerges: one user's agent tasks another user's agent. Contractor and client, supplier and buyer — their agents negotiated the details, updated records on both sides, and the people saw the finished result. The people didn't message each other.

That's not today, but it's the logical continuation: if an agent has context and hands, sooner or later it will need a peer-class counterpart.

Give your agent context. Registration at vibe.korfix.info is free and requires no credit card. Create a catalog, generate a token with minimum permissions, connect via MCP — and see the difference between AI that reasons and an agent that works with your data.