From tool calls to an agent computer: how the architecture changes

Imagine adding a supplier-comparison button to your product. A customer selects several quotes and asks for a spreadsheet showing prices, delivery dates, and differences in the terms. Your first prototype sends the text to a model. It works on a short quote. Then a customer provides scanned PDFs, a spreadsheet, and a link to a supplier’s website.

The feature now needs to open files, extract tables, check the website, calculate comparable prices, and create a downloadable spreadsheet. The model helps decide what to do. It also needs somewhere to run the programs that do it. This is where an agent computer becomes useful.

What happens after the model asks to run a command?

A tool call is a request from the model to your program. For example, the model might ask to run a script that reads the quotes. Your program still needs to provide the input files, install the parser, execute the script, and return its output. If the parser fails on a scanned page, the agent needs to inspect that failure and try another available extraction method.

You can build those steps yourself. As the feature grows, you also need a browser, file access, command output, and a way to keep each customer’s work separate. Beeuni brings these into a session: the agent works on a cloud computer where it can read files, write code, run commands, and use the browser.

For the comparison, the agent can save extracted rows, write a calculation script, and run it. It can visit a public supplier page to check a delivery condition. When a row has no clear unit or delivery date, the output can flag that gap for review. The useful result is a spreadsheet with source references that the customer can inspect.

From a tool loop to work running on a computer

The familiar tool loop still does the reasoning: ask the model, execute its requested action, return what happened, and ask again. For the PDF step, the computer runs an extraction script and returns its exit code, output, and errors. The agent reads those results before deciding what to do next. A failed parser, an empty table, and a successful extraction should lead to different next steps.

Keep the original PDF, extracted.csv, the calculation script, and the final spreadsheet as separate files. If the final numbers look wrong, you can follow them back through those files. Ask the agent to compare an extracted row with the original page before changing the calculation. This makes it possible to fix the step that lost the information.

A tool can also start a process that outlasts the call itself. A document-conversion job may still be running when the request times out. The execution layer needs a way to inspect that process and its output. Asking the model to launch it again could create two conversions instead of fixing the delay.

Give separate tasks separate working environments

When two comparisons share a directory, either can overwrite extracted.csv or install a package version the other cannot use. Each Beeuni session has its own execution environment, keeping those local files and processes apart. For repository-backed work, its branch also lets you review code changes before accepting them into the default branch.

Shared applications need separate attention. If both sessions can update the same purchasing record, different computers do not prevent conflicting edits there. Decide whether the comparison only reads those records, or whether an update needs approval.

Decide what must survive a stop or failure

The saved session tells you what the agent did. The disk holds the extracted files and spreadsheet. A running process holds work it has not yet written. These are different kinds of state: recovering the messages does not mean a conversion process resumes from its previous instruction.

A normal stop preserves the computer’s disk. Deleting or losing the computer requires a different recovery path, using saved conversation and repository work where available. Save important outputs to your chosen storage and push repository changes you need. The session guide explains what each operation retains.

Put permissions on the actions that matter

The comparison agent may need to read supplier documents while placing an order requires a person’s decision. Beeuni’s connector policies can allow a tool action, require approval, or block it. Configure the action itself rather than relying entirely on a sentence in the task. A computer can isolate local work while its connected tools still affect a real purchasing system.

Your product also checks which customer may open each comparison and its files. A server-held API key authenticates your application to Beeuni. Your own access checks connect that request to the person allowed to see the result.

Let long tasks continue beyond one connection

A customer can close the page while a conversion is running. Store the Beeuni session ID with the comparison record so the returning page can find the same work. Event streams show live progress; saved logs let it catch up afterward. A reachable computer may be busy, finished, or waiting for input, so show the task’s state as well as the computer’s availability.

Before repeating an interrupted request, inspect what happened. This matters especially for external actions: an order may have been created even if its confirmation never arrived. The agent backend walkthrough covers the application-side records and reconnect handling.

Make failures easy to investigate

Suppose the generated sheet has an empty price column. Open the session’s files and command output. Did the PDF parser return no rows? Did the script expect a column named Price when the quote used Unit cost? Did the supplier page require a sign-in? Each cause leads to a different fix.

Because the agent is working with files and programs, you can ask it to inspect an intermediate CSV, correct the column mapping, and rerun the calculation. That is often more useful than asking the model to generate its final answer again without knowing what failed.

Improve the slow step you can actually see

For this feature, time can go into preparing the computer, model responses, document extraction, and website loading. Look at a real comparison before changing the architecture. If the agent repeatedly opens the same PDF, save the extracted text and work from that. If a calculation script is slow, inspect the script. If the supplier website is slow, changing the model will not make that page load faster.

Check the spreadsheet after each change. Faster extraction is only helpful if it still captures the prices and terms correctly. Compare the same documents with the same model settings so you can see whether the change helped.

What the architecture now provides

The model still chooses actions through a tool loop. Around it, the service now runs programs, separates tasks, retains useful work, applies permissions, and exposes progress. That is the architectural change behind an agent computer. Beeuni provides those execution and session interfaces so your application can send a task and inspect the work as it happens.

The same arrangement can support a dataset-preparation feature or a browser-testing tool. The files, commands, and expected outputs change. Your product still starts a session, follows the work, and presents a result the customer can use.

Start with Sessions from code and Authentication. For the broader product idea, read What is an AI computer?.