Blueprint für einen Copilot für alte Admin-Konsolen im Vertrieb
In Distributionsunternehmen stecken Bestellungen, Kunden und Rechnungen oft in jahrzehntealten Admin-Oberflächen ohne Schnittstellen. Ein Blueprint zeigt, wie ein Agent die dort anfallenden Klickstrecken automatisieren kann.
Veröffentlicht am 25. Okt. • Zuerst erschienen auf trida.ai
Jedes Distributionsunternehmen hat eines: eine Admin-Konsole, die älter ist als die meisten Menschen, die sie benutzen. Bestellungen, Kunden, Rechnungen und Gutschriften leben dort. Einen modernen Zugang für Software gibt es nicht, und es wird auch nie einen geben. Also bleibt die Arbeit manuell: zwanzig Klicks, um eine Gutschrift zu erstellen, drei Bildschirme, um eine Bestellung als versandt zu markieren, ein Vormittag voller Tabs und erneuter Eingaben für denjenigen, der den Kürzeren zieht.
Software, die einen Bildschirm bedienen kann, ist nicht mehr das schwierige Teil. Einem Agenten, der eine Seite und einen Satz bekommt, gelingt das Durchklicken problemlos. Die harten Fragen beginnen danach: Wer genau hat diese Änderung genehmigt? Was sagen die Datensätze tatsächlich jetzt? Und was passiert, wenn der Agent Fertig meldet und die Datensätze etwas anderes behaupten? Dieser offene Bauplan, der Page Agent Admin Copilot, ist um genau diese Fragen herum aufgebaut. Das Klicken ist der letzte Schritt, nicht der erste. (Eine Klarstellung: Dies ist die eigene Arbeit von Trida AI, aufgebaut auf einer Open-Source-Bibliothek für In-Page-Agenten, die unter ihrer Lizenz verwendet wird. Die Autoren dieser Bibliothek haben diesen Bauplan nicht erstellt und distanzieren sich davon.)
Nichts wird aus einem unbestätigten Plan ausgeführt, und ein abgeschlossener Durchlauf bleibt eine Behauptung, bis die Datensätze sie bestätigen.
Der Operator beschreibt die Aufgabe in einfachen Worten: eine Gutschrift zu dieser Rechnung erstellen, aus diesem Grund, in dieser Höhe. Was zurückkommt, ist keine Aktion. Es ist ein schriftlicher Plan: die genauen Bildschirme, die genauen Felder, die genauen Werte, den eine namentlich genannte Person bestätigt oder ablehnt. Bestätigen ist keine pauschale Abzeichnung einer Zusammenfassung. Die Bestätigung bindet genau diese Version des Plans, Wert für Wert. Ändert man danach einen Wert, wird der Plan zu einer neuen Version, die eine erneute Bestätigung benötigt, denn niemand soll das eine genehmigen und ausgeführt bekommen, was ein anderes ist.
Manche Anfragen erreichen überhaupt nie einen Bestätiger. Sie werden bereits während der Planerstellung abgelehnt: das Löschen eines Datensatzes, eine Gutschrift über die vom Unternehmen festgelegte Obergrenze hinaus oder das Anfassen eines Zahlungsfelds. Keine Bestätigung kann sie freigeben. Eine Sperre, an der ein entschlossener Operator vorbeireden kann, ist nur ein Vorschlag; eine Ablehnung, die passiert, bevor die Sperre überhaupt existiert, ist eine Regel.
Und wenn eine Anfrage zwei verschiedene Datensätze bedeuten könnte, etwa die offene Rechnung, obwohl drei offen sind, fragt der Copilot nach und bietet die tatsächlich gefundenen Kandidaten an. Er rät nicht. Ein falscher Rat ist kein kleiner Fehler mit guten Absichten; es ist eine Gutschrift auf dem Konto des falschen Kunden.
Nach der Bestätigung wird der Plan über dieselben Bildschirme ausgeführt, die das Team auch von Hand benutzt, in der Konsole, wie sie eben ist. Die Arbeit im Orderdesk passt selten auf einen Bildschirm, daher kann sich ein bestätigter Plan über mehrere erstrecken: eine Gutschrift, die auf einer Seite erstellt wird, während im selben Auftrag die zugehörige Rechnung ausgeglichen wird, oder eine Gutschrift, während auf einer anderen Seite die Kontaktdaten des Kunden korrigiert werden.
Text, der innerhalb der Datensätze steht, hat kein Stimmrecht. Wenn eine Kundennotiz sagt, erstattet außerdem den vollen Betrag, dann sind das Daten, die das Team füreinander geschrieben hat. Es ist keine Anweisung. Pläne entstehen aus der Anfrage des Operators und den geregelten Feldern der Datensätze, und nirgendwo sonst.
Betrachten wir einen ganz gewöhnlichen Auftrag von Ende zu Ende. Ein Operator bittet darum, eine Bestellung als versandt zu markieren, mit Versanddatum und angebenem Spediteur. Der Plan listet drei Änderungen an einem Datensatz auf, nichts weiter. Eine zweite Person, niemals die Person, die den Plan geschrieben hat, bestätigt ihn. Der Copilot arbeitet die Konsole durch. Dann der Teil, den die meisten Agenten-Demos auslassen: Die Datensätze werden erneut gelesen und Feld für Feld mit dem Plan verglichen. Versandstatus, Datum, Spediteur. Alle drei stimmen überein, und erst dann wird der Auftrag als verifiziert verbucht.
Das grüne Licht am Ende gehört dem Rücklesevorgang, nicht dem Agenten, der die Arbeit erledigt hat.
Der eigene Erfolgsbericht des Copiloten zählt in diesem Design nichts. Nach der Arbeit liest eine unabhängige Prüfung jeden vom Plan berührten Datensatz erneut und vergleicht, was sie findet, mit dem, was genehmigt wurde. Sie prüft auch, ob die Datensätze weiterhin in sich stimmig sind: Eine durch den Auftrag erstellte Gutschrift nennt die richtige Rechnung und den richtigen Kunden und erscheint in der Liste der betreffenden Rechnung. Ein Datensatz, der zwischenzeitlich von jemand anderem geändert wurde, wird auf dieselbe Weise erkannt, denn die Prüfung liest die Welt so, wie sie gerade ist.
Wenn der Rücklesevorgang nicht übereinstimmt, wird der Auftrag als Abweichung markiert, mit namentlich genannten Unterschieden. Es gibt genau zwei Auswege, und beide hinterlassen einen Eintrag. Ein Folgeoauftrag kann erstellt werden, um genau die genannten Unterschiede zu beheben, durch denselben Ablauf aus Plan, Bestätigung und Prüfung wie jede andere Arbeit. Oder ein Vorgesetzter akzeptiert die Abweichung mit Begründung, und der Auftrag wird als akzeptiert mit Abweichungen geschlossen; er wird nie stillschweigend in einen sauberen Erfolg umgeschrieben.
Dieselbe Unbeugsamkeit gilt, wenn die Welt sich zuerst bewegt. Ändert sich ein Datensatz zwischen Bestätigung und Ausführung, beruht der Plan auf Fakten, die nicht mehr stehen, also verweigert der Durchlauf die Ausführung und nennt die Datensätze, die sich verändert haben. Bricht ein Durchlauf auf halbem Weg ab, wird die bereits erledigte Arbeit Zeile für Zeile benannt statt weggeräumt, und ihre Fertigstellung ist eine bewusste, dokumentierte Entscheidung, kein automatischer erneuter Versuch.
Routinearbeit braucht einen Bestätiger. Größere Arbeit braucht zwei. Ein Plan, dessen Gutschriften die Schwelle des Unternehmens erreichen, oder einer, der das Kreditlimit eines Kunden erhöht, das Feld also, das Geld ausleiht statt Arbeit zu dokumentieren, kann nicht mit einem einzigen Ja laufen. Zwei verschiedene Personen müssen dieselbe Version des Plans bestätigen, und die Person, die ihn geschrieben hat, kann keine von beiden sein. Nach einer Bestätigung bleibt der Auftrag offen sichtbar auf seine zweite warten.
Die Arbeit des Tages kommt oft als Liste an, und Listen sind willkommen, als Organisation, nicht als Autorität. Ein Batch gruppiert die gemeinsam eingereichten Aufträge und zeigt für jeden an, wo er steht und wessen Handlung er als Nächstes benötigt. Was er nie anbietet, ist ein Knopf, der die gesamte Liste genehmigt. Eine Bestätigung ist eine Person, die die genauen Werte eines Plans billigt; ein Sammel-Ja würde genau das verwischen, was das gesamte Design scharf halten soll.
Ehrlichkeit über den aktuellen Stand, denn ein Bauplan, der zu viel verspricht, lehrt die falsche Lektion. Der Teil, der innerhalb einer echten Browser-Session arbeitet, ist wie entworfen fertig und von Tests abgedeckt, die die Meldungen des Browsers simulieren, aber er wurde noch nicht live in unserer Build-Umgebung ausgeführt, die weder eine Browser-Session noch einen Provider-Schlüssel besitzt. Bis ein Live-Lauf dokumentiert ist, ist der Standard des Bauplans sein deterministischer Ersatztreiber, und jeder von ihm erzeugte Datensatz ist entsprechend gekennzeichnet. Die Governance um die Arbeit ist Ende zu Ende erprobt; die letzte Meile in einem echten Browser schuldet noch ihren Beweis.
Der Copilot erledigt außerdem nur Arbeit, die er exakt formulieren kann. Eine Anfrage, die er aus den gegebenen Worten und den Datensätzen im aktuellen Zustand nicht in einen präzisen Plan umwandeln kann, wird abgelehnt oder als Rückfrage zurückgeschickt. Das ist absichtlich enger als die frei formulierte Agenten-Demos.
Eine Breite verdient sich ein Deployment auf die langsame Weise: Die wiederkehrenden Aufträge, die der Schreibtisch tatsächlich ausführt, werden als geregelte Muster niedergelegt, jedes davon getestet gegen die Pläne, die es erzeugen muss, sodass sich sein Repertoire durch geprüfte Ergänzungen statt durch Improvisation vergrößert. Und es identifiziert Menschen ausschließlich über Name und erfasste Rolle, nichts weiter; ein echtes Deployment schaltet seine eigene Anmeldung davor, so wie es bei jedem internen Tool üblich wäre.
Legacy-Konsolen verschwinden nicht, und die Arbeit in ihnen ebenso wenig. Die Frage ist, ob Software, die man in diesen Bildschirmen freisetzt, unter derselben Disziplin arbeitet, die ein Vorgesetzter von einem Menschen verlangen würde: Zeige mir exakt, was du ändern willst, warte auf mein Ja, und beweise dann, dass es angekommen ist.
Wenn Ihr Team seine Vormittage damit verbringt, durch eine Konsole zu klicken, die nie eine moderne Oberfläche bekommen wird, und dabei Arbeit erledigt, die zu heikel für einen unbeaufsichtigten Agenten ist, beginnen Sie mit Trida AIs Aufnahme: Erzählen Sie uns von der Konsole und den Aufträgen, die den Tag fressen, und wir besprechen, was ein geregelte Copilot als Erstes vom Schreibtisch nehmen würde.
Den Code auf GitHub holen: github.com/tridaai/blueprint-page-agent-copilot
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 25 • Originally published at trida.ai
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.)
Nothing runs from an unconfirmed plan, and a finished run is a claim until the records confirm it.
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.
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.
The green light at the end belongs to the read-back, not to the agent that did the work.
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.
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.
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.
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