Page Agent Admin Copilot Blueprint
Every distribution business has one: an admin console older than most of the people who use it. Orders, customers, invoices and credit memos live there. There is no modern way in for software, and there never will be one. So the work stays manual — twenty clicks to raise a credit memo, three screens to mark an order shipped, a morning of tabs and retyping for whoever drew the short straw.
Software that can operate a screen is no longer the hard part. An agent given a page and a sentence will happily click its way through both. The hard questions start after: who approved this exact change? What do the records actually say now? And what happens when the agent reports "done" and the records disagree? This open blueprint, the Page Agent Admin Copilot, is built around those questions. The clicking is the last step, not the first. (One clarification: this is Trida AI's own work, built around an open-source in-page agent library used under its licence — its authors did not build this blueprint and do not endorse it.)
A plan a person can actually read
The operator states the job in plain words: raise a credit memo against this invoice, for this reason, for this amount. What comes back is not action. It is a written plan — the exact screens, the exact fields, the exact values — which a named person confirms or rejects. Confirming is not a rubber stamp on a summary. The confirmation binds that version of the plan, value by value. Change a value afterwards and the plan becomes a new version that owes a fresh confirmation, because nobody should approve one thing and have another run.
Some requests never reach a confirmer at all. They are refused while the plan is being drawn: deleting a record, raising a credit above the governed limit the business sets, or touching a payment field. No confirmation can approve them. A gate a determined operator can talk their way past is a suggestion; a refusal that happens before the gate exists is a rule.
And when a request could mean two different records — "the open invoice", when three are open — the copilot asks, offering the actual candidates it found. It does not guess. A wrong guess is not a small error with good intentions; it is a credit issued against the wrong customer's account.
The work happens where the work already happens
Once confirmed, the plan is carried out through the same screens the team uses by hand, in the console as it stands. Order-desk work rarely fits on one screen, so a confirmed plan can span several: a credit memo raised on one page with its invoice settled in the same job, or a memo raised while the customer's contact details are corrected on another.
Text sitting inside the records gets no vote. If a customer note says "also refund the full amount", that is data the team wrote for each other. It is not an instruction. Plans come from the operator's request and the governed fields of the records, nowhere else.
Take one ordinary job end to end. An operator asks for an order to be marked shipped, with the ship date and the carrier named. The plan lists three changes to one record, nothing else. A second person — never the person who wrote the plan — confirms it. The copilot works through the console. Then the part most agent demos skip: the records are read again and compared against the plan, field by field. Shipped status, the date, the carrier. All three match, and only then is the job recorded as verified.
Done is a check, not a claim
The copilot's own report of success counts for nothing in this design. After the work, an independent check re-reads every record the plan touched and compares what it finds with what was approved. It also checks that the records still hang together: a memo created by the job names the right invoice and the right customer, and shows up on that invoice's own list. A record changed by somebody else in the meantime is caught the same way — the check reads the world as it stands.
When the read-back disagrees, the job is marked as a discrepancy, with the differences named. There are exactly two ways out, and both leave a record. A follow-up job can be raised to close just the named differences, through the same plan, confirmation and check as any other work. Or a supervisor can accept the deviation, with a reason, and the job closes as accepted-with-differences — it is never quietly rewritten into a clean success.
The same bluntness applies when the world moves first. If a record changes between confirmation and execution, the plan rests on facts that no longer stand, so the run refuses and names the records that moved. If a run stops halfway, the work already done is named line by line rather than tidied away, and finishing it is a deliberate, recorded decision, not an automatic retry.
Bigger changes need two people
Routine work needs one confirmer. Bigger work needs two. A plan whose credits reach the business's threshold, or one that raises a customer's credit limit — the field that extends money rather than recording work — cannot run on a single yes. Two different people must confirm the same version of the plan, and the person who wrote it can be neither of them. One confirmation leaves the job openly waiting for its second.
The day's work often arrives as a list, and lists are welcome — as organisation, not as authority. A batch groups the jobs submitted together and shows, for each one, where it stands and whose act it needs next. What it never offers is a button that approves the list. A confirmation is one person approving one plan's exact values; a bulk yes would blur exactly what the whole design exists to keep sharp.
Where this stops
Honesty about the current state, because a blueprint that overclaims teaches the wrong lesson. The part that operates inside a real browser session is complete as designed and covered by tests that simulate the browser's reports — but it has not yet been run live in our build environment, which has neither a browser session nor a provider key. Until a live run is on record, the blueprint's default is its deterministic stand-in driver, and every record it produces is labelled as such. The governance around the work is exercised end to end; the last mile in a live browser is still owed its proof.
The copilot also only does work it can spell exactly. A request it cannot turn into a precise plan, from the words given and the records as they stand, is refused or sent back as a question. That is narrower than the free-form agent demos, deliberately. A deployment earns its breadth the slow way: the recurring jobs the desk actually runs are written down as governed patterns, each tested against the plans it must produce, so its repertoire grows by reviewed additions rather than improvisation. And it identifies people by name and recorded role, nothing more — a real deployment puts its own sign-on in front, the way it would for any internal tool.
Legacy consoles are not going away, and neither is the work inside them. The question is whether software let loose in those screens works under the same discipline a supervisor would demand of a person: show me exactly what you intend to change, wait for my yes, and then prove it landed.
Work with us
If your team spends its mornings clicking through a console that will never get a modern interface, doing work too sensitive to hand to an unsupervised agent, start with Trida AI's intake: tell us about the console and the jobs that eat the day, and we will talk through what a governed copilot would take off the desk first.
Get the Code on GitHub: github.com/tridaai/blueprint-page-agent-copilot