In July, the employee who handled our referral partners left the company: contracts, statements of work, invoices, approvals, payouts. We did not look for a replacement. On Saturday, 5 September, I described the process in plain words to the TunnelCode agent in GPTunneL. On Sunday the pipeline went to production. On Monday, 7 September, the first real partner went through it without a single message from me. Three days for a function the company used to keep a full-time position for.
Below is a step-by-step account: what the person actually did, how the replacement works, what it cost, and why not a single partner ID document ended up inside a neural network. This is not a model review or a prompting tutorial. It is a case study for a manager who has a similar process somewhere in the department.
What the person did: seven steps and four systems
The GPTunneL referral program is simple: a partner brings in clients and receives a percentage of their payments. The complexity starts where that percentage has to become money in the partner's bank account, with a contract, a statement of work, an invoice, and everything done by the book.
One payout with a human employee looked like this.
- The partner submits a payout request in their account.
- The employee takes a contract template from shared storage and fills in the partner's details.
- Creates a task for the lawyer and waits for approval.
- Sends the contract to the partner and waits for a signed scan or an electronic signature.
- Asks the partner for a statement of work and an invoice. A freelancer usually does not know how to prepare them, and the correspondence goes in circles.
- Creates a payment task and walks it through three approvers.
- Hands it over to the accountant and, for freelancers, also asks for a receipt.
Seven steps, four systems, and waiting at every step. Not because the employee was bad, but because there was one of them, with working hours and a dozen other tasks. A request that arrives on Friday evening does not exist until Monday.
Why hiring a new manager would have been a mistake
Break the process down into decisions and it turns out there are only two human ones: the lawyer approving the contract and the approval of the payment. Both were made by other people. Plus one technical action on the platform, debiting the partner's balance. Everything else is moving data from one system to another and waiting.
The employee was a dispatcher between the people who make decisions. A new manager would have inherited the same queue, the same working hours, and the same two weeks of vacation during which the process stops. What made sense to replace was not the person but the dispatcher role.
An evening for the specification, a day for the code
There was no "implementation" in the usual sense. There was one evening during which TunnelCode and I wrote a specification: who the partners are (individuals, freelancers, sole proprietors), which templates the contract is assembled from, who approves what, and which systems the tasks live in. The agent split the specification into 17 tasks and wrote a deterministic Python service inside our backend, with 281 automated tests.
Here is what came out of it.
The request is a web form. The partner fills it in once: status, payment details. There is no need to enter the rate: the bot checks the percentage and the number of referrals against our analytics. The form response lands as a task in the task tracker, and from that moment the bot owns the request.
The contract is assembled from the lawyers' template. The same placeholders a human used to fill in are now filled in by code: no typos in the tax ID, the date in the company's time zone, the details in the correct grammatical form. The lawyer receives a ready task with a docx and a pdf and approves it.
The partner receives an email with the contract. Their reply with the scan lands as a comment in the same task. Sole proprietors who use electronic document exchange get an invitation there instead.
The bot prepares the statement of work and the invoice itself, for the request amount, under the signed contract. The partner no longer needs to know what a statement of work is.
The payment task is created automatically, with the statement and the invoice attached. Approvers see the full set at once.
If there is silence at any step, the bot follows up. Not with one email, but with an escalating sequence and its own reminder budget for every stage.
Where the bot beats the employee
Not "as good as a human" but better, and here is exactly where.
| Before: employee | After: bot | |
|---|---|---|
| Reaction to a request | during working hours, when they get to it | immediately, around the clock, weekends included |
| Statement of work and invoice | asks the partner, the partner cannot prepare them | prepares them itself for the request amount |
| Rate and number of referrals | looks them up in the admin panel, copies by hand | takes them from analytics by partner ID |
| Errors in payment details | human: a typo in the tax ID, an old date | placeholders filled by code, date in the right time zone |
| Reminders | "forgot to write" | escalating sequence for every stage |
| Consent to data processing | one copy inside the contract | date and document version for every request |
| Ten requests instead of one | a queue of weeks | the same few minutes |
| Vacation, sick leave, resignation | the process stops | does not happen |
The consent row is a story of its own. The lawyer had long asked for consent logs. The human employee did not keep them: not out of malice, it is simply something nobody keeps by hand. The bot records the consent date and the document version for every request because it costs it nothing.
The second thing that turned out to matter more than expected: the bot shows no initiative where it should not. If there is not enough data for the contract, it does not guess. It stops and writes exactly what is missing. A human at this point usually promises to clarify later.
What stayed with people
Decisions. The lawyer approves the contract, and until that approval neither the signature nor the sending to the partner happens. Payment goes through a task with three approvers. Debiting the partner's balance on the platform is something I do myself when notified.
| Role | What they do | What they get from the bot |
|---|---|---|
| Partner | fills in the form once, signs the contract | contract, statement and invoice ready-made, reminders about the next step |
| Lawyer | approves the contract | a task with docx and pdf, consent logs |
| Payment approvers | give approval | a task with the statement and invoice attached |
| Accountant | executes the payment | a complete document set, the freelancer's receipt |
| Manager | debits the partner's balance | a notification when everything is approved |
The bot replaced the dispatcher, not the lawyer and not the accountant. The difference is that there is no more waiting between their decisions.
What it cost
A weekend, and the tokens TunnelCode spent on the specification and the code. Pay per use, no subscription. Development came out cheaper than one working day of a manager.
After that, zero. There is no neural network at runtime, so every subsequent request costs nothing. This is the key point: the process knowledge that left with the employee is transferred into code once and is never spent again on each partner.
For comparison, a manager's position is not just a salary. It is also a week to a month per payout, partners who do not know how to prepare a statement of work, and a process that stops for two weeks of vacation.
"You handed partner ID documents to a neural network"
That was the first objection I heard. We did not. The neural network wrote code; it did not read ID documents. These are two different agents with different access.
TunnelCode as the developer received a description of the process: contract templates with placeholders instead of real details, a description of the admin panel, the queue structure, the approval rules. The test requests were a fictional freelancer and a fictional sole proprietor with a nominal amount. Not a single real name.
The bot as the executor is plain code with no model calls. The partner enters their details as text in form fields, scans are simply stored as files, emails are templates with the name substituted. The entire personal data processing loop stayed exactly where it was with the human employee: the form service, the task tracker, corporate email, Postgres on our own hosting. Not a single new processor in the scheme, which means not a single new line in the consent and no cross-border transfer.
The temptation to let a model recognise a photo of an ID document was there. We declined: that is a separate legal basis, a separate notification to the data protection regulator, and a separate point of failure, all so the partner does not have to type in a document number by hand. A bad trade. Not one step of the pipeline got worse because there is no model in it.
This is not legal advice; your own case is for your lawyer to review. But the principle carries over to any automation: the agent that builds the process needs the process. The code that runs it needs the data. These are different things, and their access should be different.
What goes wrong if you repeat this
- The specification is written in broad strokes. The agent faithfully implements what is described. If the description has no case for "the partner sent a scan without a signature", the bot will have to be extended after the first such partner. An hour spent listing the exceptions saves days.
- Decisions are handed to the bot too. Contract and payment approval must stay with people, otherwise the first error in payment details goes out to the partner and on to accounting.
- A model is left in the runtime. Every request starts costing money, and the answers become non-deterministic. The model is needed at the development stage; at execution, code is enough.
- Real data ends up in the tests. Test partners must be fictional from the very start, otherwise personal data ends up in the development context.
What to do on Monday
Take one process that a single person runs and write it out step by step, as in the first section. Mark where the real decisions are and where it is just data transfer and waiting. If there are two or three decisions and seven steps, it is a candidate for the same kind of pipeline.
You can build it the same way: TunnelCode is a coding agent inside GPTunneL. It sees the whole project, edits dozens of files at once, runs tests, reads errors, and fixes them itself. No subscriptions, pay per use. If the process is more complex or you need help describing it, there is implementation consulting, terms for companies are on the business access page, and model prices are in the price list.
The GPTunneL referral program stays open: a partner receives a percentage of the payments made by the clients they bring in. Payouts now run through the pipeline described above: a request in a form, a contract from the lawyers' template, the statement and invoice prepared by the bot, and reminders that arrive on their own.