We start with one process in your company, build the agent on your systems and measure it against how the work is done today. Behind it is the system that builds and runs PolySimulator: agents that plan, build, check and operate, with a shared memory and people in charge.
With the people who do the work today, we pick one process and agree how it will be judged: time spent, error rate, throughput, or whatever the work is measured by now.
We build the agent on your systems and run it alongside the current process for a few weeks, on the same cases, so the two can be compared.
If the pilot holds up, the agent goes into daily use. We keep running and improving it, or hand it over to your team with code and documentation.
After a pilot, the system can grow: from one agent for one process, to a team of agents for a whole workflow, to standing roles with a shared memory and guards like ours.
Good first candidates are frequent, rule-bound tasks where a person checks the result today anyway.
The backlog your developers never reach: tests, migrations, internal tools and integrations, written by agents and reviewed by your team.
Systems watched around the clock, alerts turned into tickets, routine fixes prepared for a person to approve.
Tenders, specifications, supplier offers and delivery notes read, sorted and entered where they belong.
First drafts of offers from a bill of quantities, and monthly or portfolio reports assembled from the systems where the data already lives.
The rules we agree with you before an agent touches your systems.
Agents work inside scopes you approve in writing. Releases, irreversible changes and anything touching personal data need a named person.
We use only model providers you approve, under a data-processing agreement, or keep the data entirely in-house.
Each task is a ticket and each change a reviewed pull request, so you can see what an agent did and why.
Seven layers, from the people who direct the work to the systems the agents act on. It builds and runs PolySimulator today.
The two of us. We set the direction and the permissions, approve changes to user data, credentials and anything sent outside, and read the briefings.
Long-running agents with a company job: operations, business, research, this website. Usually two to four at once.
Plan a piece of work in phases, send out a team of agents in parallel, and have a critic check what comes back.
Build, test, review and research: short-lived agents with one task each. Most code changes get an AI review before they merge.
Plain programs the agents wrote and maintain: watchdogs, data reconciliation, self-healing probes. They run without a model.
Facts, decisions and lessons, synced across machines every 20 minutes. Mistakes are written down as lessons and, where possible, turned into checks.
Code, servers, market data, monitoring and mail, reached through scoped access.
Code written, tested and reviewed by agents and merged into our working branch; releases to production need one of us.
Monitoring, alerts, guards and recoveries, day and night.
Tens of terabytes of order-book data, recorded and reconciled.
A morning and an evening briefing on what changed and what needs a decision.
One of our machines went offline for eleven hours overnight. By noon the next day, agents had reviewed those hours of production, moved every production safeguard off that machine, put it under outside monitoring and verified each step, with one of us approving each production change. No production job depends on it any more.
Before a large release, three agents in parallel went through every pending change and all 50 database migrations. They found 19 that a standard upgrade would silently skip and 2 that would fail on production data, wrote previews and a rehearsal plan, and left us eight decisions instead of a risky release.
Have a process in mind for a pilot?
Write to contact@bavariance.com. A few lines about it are enough to start. We reply in German or English.