Frontend or Backend Agent Tool? Keep Display and Storage Consistent

Where should an Agent tool execute: the frontend or the backend?

My main rule is: when an operation affects frontend state and must keep the displayed result consistent with backend storage, it should call an existing frontend business action.

Consider changing a chart’s indicator configuration. The chart must change, the settings panel must show the corresponding configuration, and the backend must persist it. Updating only one of those is incomplete.

An Agent should enter the same operation used by a person editing those settings: validate, request the save, handle the response, and update Store state so the UI reflects the outcome.

An independent data query or background computation can be a backend tool. Pure interface operations such as selecting an interval or filling a form also belong on the frontend. The important case is the operation spanning display and storage: writing to a database does not automatically make the whole tool a backend tool.

Start with the states that must agree

Suppose an Agent saves indicator settings through a backend tool while the frontend Store retains the old configuration. The database has changed, but the chart and settings panel still use the previous values. A subsequent manual save might even write those old values back.

A success message does not resolve that mismatch. The operation must coordinate the state the page uses with the state the server actually saved.

Operation	Entry point	Reason
Change and save the current chart’s indicator configuration	Frontend business action	Chart, settings panel, and persisted configuration must follow one flow
Edit and save a business object displayed on the page	Frontend business action	Editing state, save outcome, and displayed values must agree
Change an interval or fill a form	Frontend business action	Frontend state must follow existing interaction rules
Query data for Agent analysis	Backend tool	No corresponding frontend business-state change is required
Run independent background computation	Backend tool	Execution and result storage must survive the page closing

Backend results may still appear in the UI. Displaying a job’s progress through an existing subscription does not require moving its computation into a frontend tool.

The distinction is whether the operation itself needs to coordinate frontend business state and the saved result.

A frontend tool can save through the backend

“Frontend tool” identifies the business entry point coordinating the operation. It does not mean all work happens in the browser.

A save action can validate input, mark the operation as pending, call an API, and update the Store from the server-confirmed result. On failure, it follows the existing business contract for retaining a draft, restoring confirmed values, or showing an error.

The Agent should reuse that contract. The server still owns permissions, business constraints, and persistence. The frontend action connects the outcome to the state used by the page.

Consistency does not imply an instantaneous transaction across browser memory and the database. Pending, saved, and failed states must be explicit; an unsaved value must not masquerade as a saved result.

Rather than asking whether a tool makes a network request or writes a database, ask: Would bypassing the frontend business action change the stored record while leaving frontend state behind? If so, reuse that frontend entry point.

Stores bind the operation to the UI

Separate components from business operations. Components display state and collect input. Store actions coordinate state transitions. Domain rules and repository access can remain in their own modules.

A Store provides shared page state and named operations. Settings controls and a chart can subscribe to the same configuration. A save action coordinates validation, persistence, and state updates; both views then respond to the same state.

User → Component event ──────────┐
                                ↓
                           Store action
                                ↑
Agent → Frontend tool adapter ───┘
                                │
                      Validate / mark pending
                                │
                         Backend save API
                                │
                 Update Store from success or failure
                                │
                          UI subscriptions

The tool calls an action, the action coordinates persistence and state, and the UI subscribes to that state. The component does not need to know whether the caller was a person or an Agent.

Expose business actions rather than arbitrary state writes. Directly changing an internal field can bypass validation, saving, and failure handling—the behavior the tool should reuse.

This sketch illustrates the relationship, rather than the complete implementation:

const saveConfiguration = (changes) => chartPort.setIndicators(changes);

// User entry point
onSave = (changes) => saveConfiguration(changes);

// Agent entry point, after target and argument validation
invokeFrontendTool = async ({ changes }) => {
  const receipt = await saveConfiguration(changes);
  return { receipt, state: chartPort.inspect() };
};

The current Store tool boundary

The current frontend_store tool uses explicitly registered ports:

Operation	Purpose
`list`	Discover available mounted targets
`inspect`	Read limited state, available actions, and argument schemas
`invoke`	Validate and call an operation, returning its receipt and current state

Chart actions include setTimeframe, draw, clearDrawings, setIndicators, and resetIndicators. The Backtest form exposes setFormValues. Navigation, server job submission, and retries keep their existing tools.

This is not automatic export of every Store method. A target must identify the intended mounted instance. If that target changes or disappears, an old call must not silently modify a replacement.

The extra synchronization path this avoids

When a backend tool bypasses the frontend flow to save a change, another mechanism is often needed to notify the browser, identify the affected object, refresh its Store, and handle drafts or late results.

That creates an additional path: backend state change → frontend notification → displayed-state reconciliation.

Calling the existing frontend business action keeps the Agent inside the normal edit, save, and state-update flow. Backend APIs persist the result; Store subscriptions update the UI. Manual and Agent-driven operations follow the same rules, without a second Agent-specific notification mechanism.

Tool delivery and result reporting still need communication. Background progress, cross-device changes, and other users’ edits still need their own synchronization. Sharing an action does not remove those responsibilities.

Nor does it make asynchronous work instantaneous. Receipts must distinguish pending requests, confirmed saves, and failures. The UI should reflect the same outcome.

A decision sequence

Does the operation affect frontend business state, such as configuration or an object being edited?
Must the displayed and stored results remain consistent? If so, call the existing frontend business action.
Which responsibilities are independently backend work? Keep queries, computation, server validation, and persistence there, accessed through their existing interfaces.
Do the button, tool, and relevant views share the same actions and Store state?
What happens on save failure, interruption, or target replacement? Do not present unconfirmed state as a saved result.

Draw the boundary around the complete business operation. When it affects frontend state and needs consistent display and storage, let the Agent call the frontend business action. The Store connects that operation to the UI, while the existing backend interface persists the result.