The pitch for agents is usually a demo day: one product, one perfect flow. This video is a Tuesday.
The agent layer does not replace the five systems a company runs; it sits over them and reaches each one through the door that system already provides. On an ordinary Tuesday one agent reads an order, checks stock and the customer's balance, updates the sales system and hands the exception to a person. The design is one table: per door, what the agent may read, propose and change.
Each chapter starts the video at that point.
The pitch for agents is usually a demo day: one product, one perfect flow. This video is a Tuesday. A company of eighty people, five systems from three vendors, and one agent doing the morning's work across all of them. I will show what it reads, what it is allowed to change, and where it stops and hands the job to a person, because that last part is the whole design. Everything on screen is a mock demo with sample data: an invented company, invented orders and invented systems drawn as plain boxes.
The shape is real; the names are not. Here is the company. A web shop takes the orders. An inventory system holds the stock in two warehouses. An accounting system holds the invoices and who owes what. A sales system holds the accounts and the deals. And a support queue holds the tickets. Three vendors, five logins, and until this year five people copying between them. The agent layer sits above all five. It did not replace any of them, and that is the point for a company that will not rip out its accounting system to get an agent.
The layer reaches each system through the door that system already provides, the same door a connector or a report would use, with its own credential and its own scope. Five doors, one agent. Five past eight. An order lands in the web shop: forty units of a product to a customer the company has sold to before. The agent reads it. It reads the inventory system next: twenty-two units in the main warehouse, thirty in the second. It reads the accounting system: this customer has an invoice forty days overdue.
Three systems read, nothing changed yet, and the agent now knows more about this order than the person who used to key it in. Then it reasons. The order can ship from two warehouses, but the customer is overdue, and the company's written rule says an overdue customer's new order is held until a person decides. So the agent does not ship it. It writes up what it found. This table is the design. One row per system, three columns: what the agent may read, what it may propose, what it may change on its own.
In the web shop it reads orders and changes nothing. In the inventory system it reads stock and may propose a transfer between warehouses, which a person approves. In the accounting system it reads balances and changes nothing; the accountant owns that door. In the sales system it may update the account's activity and open a note. In the support queue it may open a ticket and assign it. Notice what is in the change column: only the actions whose undo is cheap. A note, a ticket, an activity. Moving stock, releasing a held order, touching an invoice: those are proposals, and a proposal waits.
That table took the company two meetings to agree, and it is the most valuable thing in this video. Seven past eight. The agent has opened a ticket in the support queue, assigned to the account manager: order held, customer forty days overdue, stock available across two warehouses, proposed transfer attached. It has written an activity on the account in the sales system so the rep sees it too. Two minutes after the order landed, the right person has the whole picture and two buttons: release the order, or call the customer first.
She calls. The invoice was disputed and the dispute was settled last week; the accounting system had not been updated. She releases the order, approves the transfer, and asks the accountant to fix the invoice. The agent did the reading across five systems. She did the one thing it could not: decide, with a fact that was not in any system yet. That morning repeats forty times a day and most of them do not need a person at all: the customer is in good standing, the stock is in one place, the order ships and the agent writes the activity.
The exceptions reach people with the facts attached. That is the Tuesday. What keeps it working is unglamorous. Each door's credential is its own and is rotated. The scope table is kept when a system changes. Somebody reads what the agent did last week and finds the rule that was wrong. And when a system is replaced, the layer gets a new door, not a new design; if that system is one we would replace, we recommend Zoho for it, and the layer does not care. Designing the doors, keeping the table and reading the log is a job, and the company that does it gets the Tuesday.
One agent, five systems, one morning. The layer reaches each system through its own door, reads more than any one person could, proposes the expensive actions and takes only the cheap ones, and hands the exceptions to a person with the facts attached. If you want to see which of your systems an agent layer would reach first, and through what, we draw that map in a free sixty-minute session. We are CodeStringers. We design, build and run business systems for companies of fifty to a thousand people, and the agent layer over them.
The link is below.
We design, build, integrate and operate AI-driven, platform-agnostic integrated business solutions for operationally complex companies. Start with a conversation; we will tell you if we are a fit.
