Build it or automate it

Automate

Building writes code into your project. Automating hands a recurring order to an agent. The same need is usually served by both, and choosing one blindly costs you a week.

The case, and the fact that decides it

A customer has not paid an invoice for more than thirty days. You want to know, and you want a follow up written.

Start with what MaShop actually pushes into your repository. It creates no invoice table. Products, orders, order items, customers, stock, coupons, reviews and blog posts are there. Invoices are not, and neither are quotes or payment schedules.

So this case begins on the build side, whatever you plan to do afterwards. An agent cannot read a table that does not exist.

Face one, build it

In the chat, in build mode, ask for an invoice table and a screen in your back office. The screen lists invoices more than thirty days overdue, with the customer, the amount and the due date. MaShop writes the code into your repository, and you deploy it.

What you get. A page you own, that you open when you want, that answers on demand and never acts on its own. It costs credits once, at generation time. Redeploying afterwards is free and open to editors. Putting a project online for the first time is reserved to paid plans.

What you do not get. Nothing happens on Monday morning unless you open the page. The screen shows the problem. It does not chase anybody.

Face two, automate it

In My agents, create an agent whose two tools are reading your data and preparing an email. In Automations, hand it an order for every Monday at eight: list the invoices overdue by more than thirty days, and draft a follow up for each one.

What you get. Every Monday the agent reads the rows, writes the messages, and files them in Approvals.

What it costs. Credits every week, charged after each run at real cost, capped at thirty cents per run by default.

What you do not get. No screen. No total on demand. And nothing at all if the run needs more than 45 seconds or more than ten model turns.

The two faces read the same rows

An agent reads through one tool, and that tool is deliberately narrow. It reads named columns, 200 rows at most, with no free SQL. The tables it may open are fixed in advance.

That fixed list is a permission list, not an inventory. It names what an agent is allowed to read when the table exists. It creates nothing.

Thirteen of those tables come with what MaShop pushes: products, product variants, categories, collections, orders, order items, customers, payment transactions, stock, coupons, reviews, blog posts and blog comments.

Nine more are allowed and never created: addresses, invoices, invoice items, quotes, payments, appointments, bookings, availability and subscriptions. An agent pointed at one of them finds nothing until you build it.

So the automation only works if the data already exists, in a table it may read, in a column that says what it needs. Getting it there is build work.

The usual sequence is: build the data and the screen, confirm the rows by looking at them, then hand the recurring part to an agent.

What decides, in practice

Build it when	Automate it when
The answer is a page, a form, a calculation or a customer facing flow.	The job repeats on a calendar, every day or on set days.
It runs when somebody opens it.	The job is read the data, then write a message.
The data does not exist yet.	The data is already there and already right.
The rules change often and you want to read the code.	The steps are stable enough to be written once.

What an automation can actually do today

MaShop runs two tools of its own. Reading rows from your database, read only, 200 rows at most. Preparing an email that waits in Approvals.

Connect an MCP server and its tools are added to that. They are relayed to the service and run there, under the same permission guard, with 20 seconds per call and 4 000 characters of the answer kept.

Outside those, an agent whose sheet declares only tools with no executor, and no skill served to it, is suspended at its first attempt. Nothing is attempted and nothing is charged, and the failed run carries the reason.

Nothing is sent

MaShop has no email sender. The email tool writes a draft into Approvals and stops there.

Signing that card does not send it, and no other route would. The screen even answers that no action was held by that signature, because the draft was already filed.

So the last step of this case is yours. Copy the draft from the card and send it from your own mailbox. Plan the Monday morning around that, not around an inbox that fills itself.

Cost, on both faces

The chat in Automations mode bills exactly like the chat in Code mode. Same credits, same project, same benefits. Automations are a mode of the project you are in, not a separate workspace.

Building costs credits once per generation. Automating costs credits once per run, charged after the fact, and a failed run is charged too. A run stopped at its time ceiling is not.

A working split for this case

• Build the invoice table first. Nothing downstream works without it.
• Build the overdue screen. Look at it. Fix the data until the list is right.
• Write one memory rule for the tone of a follow up, so every draft sounds like you.
• Write one skill holding the follow up steps and what must never be said.
• Create the agent, tools set to reading and preparing an email, autonomy set to prepare and sign.
• Hand it a weekly order that quotes the skill by name.
• Read the first three Mondays in Run history, and send the first drafts yourself, before trusting the schedule.