Skip to main content
The Codenull Agent is a mode of the AI chat that works the way coding assistants do: it explores your application with small tools, narrates what it is doing, asks you when a decision is yours to make, and applies changes step by step. It runs exactly the same tools as the MCP server, so what you can do from Claude Code or Cursor you can now do from inside the platform, with the same validations, permissions and audit trail.
The mode is on by default in every application. A Clásico | Plan | Ejecutar toggle appears in the chat toolbar, with Ejecutar selected by default; the choice is remembered per browser tab. Clásico keeps the previous intent router with the designer and App Builder agents; data questions asked there are answered by the Codenull Agent too, since it is the only agent that reads or writes business data (see Query & Transaction Agents).

​
Plan mode

In Plan the agent only has read tools: it lists entities, features, hooks and menus, reads the authoring guides and the GraphQL schema, checks architecture decisions and validates code, but it never writes. It ends the turn with a plan: the steps it would take, the tools it would use and any open questions. Answer the questions to refine it, or press Ejecutar plan on the plan card: that switches the chat to Ejecutar and asks the agent to build it. While the toggle stays on Plan the agent cannot write, and it will say so if you ask it to proceed.

​
Execute mode

In Ejecutar the agent has every tool your permissions allow. Features it creates are always custom features (React code); it does not build standard configuration features. Edits apply directly to the published feature: the agent never creates drafts or versions, so if you want to review a change before it goes live, ask for it from the designer’s version flow instead. It works in a loop: read what it needs, validate, persist, and report. Each write shows a diff of the exact lines that changed. When it needs an answer from you (a name, a scope, a choice between valid options) it stops and shows a question card; answering resumes the work.

​
Charts in the chat

When you ask a data question whose answer is a distribution (“how many production orders do I have in each state?”), a time series (“sales per month this year”) or a comparison of a few series, the agent draws a chart card instead of a plain table. Ask for it explicitly (“show it as a chart”, “mostrámelo en una gráfica”) and it always does; otherwise it decides on its own when the data reads better visually, and keeps answering in text for record listings or single numbers.
  • Supported types: bar (vertical or horizontal), line, area and pie/donut, with stacked series and number, currency or percent formats.
  • Charts use your application’s theme colors unless you ask for specific ones.
  • Ver datos on the card shows the aggregated rows behind the chart as a table, so you can copy or check them.
  • The chart is saved with the conversation and renders again when you reopen it.
  • Limits: up to 200 rows, 6 series and 8 pie slices per chart; with more categories the agent uses a bar chart.
The agent gets the chart rows with a single execute_data_query call to the table’s <Plural>Aggregate query, so the database does the grouping and large tables cost the same as small ones. The chart tool exists only inside the platform chat; it is not exposed through the MCP server.

​
Leaving the chat while it works

You can navigate to other parts of the application while the agent is working: the run keeps going and, when you come back to the chat, you see it still streaming. Reloading the page or closing the tab aborts the run, so the chat warns you before you leave while a turn is in progress. Changes the agent already applied stay applied in either case.

​
Operations that wait for your approval

Some tools never run on their own: deleting a feature, hook or decision, creating or editing hooks, setting environment variables, granting feature access to roles, and writing business data. The agent shows a confirmation card with the exact arguments and nothing happens until you approve. Features, tables, menus and architecture decisions are applied directly and each change shows its diff.

​
Permissions

The full picture, with a diagram of how permissions turn into tools, is in Agent Permissions. In short, the agent derives its tools from your role, following the same rules as MCP API keys: designers get the configuration tools, only administrators get hooks, roles, environment variables and deletions, and business-data tools require the AI Search / AI Transactions agent permissions plus per-entity permission enforcement. A tool you cannot use is simply not offered. A role with only the search or transactions permission can use the agent too: it gets the data tools and nothing else. If your role has those permissions but the application does not enforce per-entity permissions, the agent has no data tools and says so when you ask for data: an administrator must enable enforcement for the application. This does not apply to administrators.