Element is building a fully automatic company. What clients get from it

2026-08-23

Element will be the first Polish ATS backed by a fully automatic company, meaning one where AI agents run the operational processes while a human picks the goals and answers for the result. The idea has been going round my head for years, but only now is the technology catching up with it. There is also plenty being written about it, including by one of my favourite podcasters. Dwarkesh Patel described this kind of organisation in an essay called The AI firm, written together with Ege Erdil and Tamay Besiroglu. His text is about a future in which AGI already exists. My question is a practical one: how much of it works today, with the models I have on hand, and what the clients paying us a subscription get out of it.

What a company of agents looks like in Dwarkesh's essay

The thesis of the essay is that most people have latched onto the question of how smart a single model will be. The way I see it, that framing misses something more important. Namely, models are digital, so they can be copied, distilled, merged, scaled and put through selection in ways that are not available to humans. Dwarkesh draws several mechanisms out of this, and in my view they are all worth walking through:

Copying, meaning capital converted into compute, and compute converted into the equivalent of your best employee. Once you have one good engineer in digital form, every further copy costs pennies.
Merging, meaning a central model that absorbs whatever its specialised copies have learned, so the boundary between individual instances stops being sharp.
Scale, which Dwarkesh puts plainly: “The cost to have an AI take a given role will become just the amount of compute the AI consumes.” Skills stop being the scarce thing. What becomes expensive are the roles that justify pouring an enormous amount of compute into a single decision.
Evolution, where the author reaches for Gwern and his question about why great companies do not simply clone themselves and take over every market. The answer is that “Corporations are made of people, not interchangeable, easily copied widgets or strands of DNA”. A company built out of models does not carry that limitation.

Which of those mechanisms already work today

Copying works, in a weaker version than the one the author describes. I do not have a copy of a brilliant engineer. What I have is many instances of the same model carrying the same set of instructions, and the cost of another instance really is compute and nothing else.

Merging works the least well of the four here, although knowledge does circulate between our agents, and a good part of that happens without me. After a harder task an agent grades where the friction was and writes a rule out of it for next time. When it trips over some trap, it appends that trap to the instruction file it was working from, without asking me first. The notes where agents keep what they have learned about our company have been growing this way for months, and the whole configuration sits in a repository wired into every machine, so a rule written on one server in the evening applies on all the others by morning.

The difference against Dwarkesh’s description is about where that knowledge lives. He writes about a model that absorbs it, which is how “Every bit of tacit knowledge from millions of copies gets perfectly preserved”. With us the knowledge stays as text next to the model. Every new instance has to read it first, and whatever nobody wrote down disappears when the session ends. In my view this still comes out cheaper than onboarding a new person, and that is exactly why automation pays off long before AGI. A procedure written down in a file copies in a second. The same procedure inside somebody’s head copies over years, if at all. It is the same mechanism Gwern describes for the replication of corporations, only at the scale of my company.

Scale matches my own experience most closely, and I will admit that the sentence about the cost of a role resonates with me strongly. That is because at my workshops I keep saying exactly the same thing: routine clicking moves over to AI, and we become the managers of agent teams, the directors. Since I started working this way, the expensive part is no longer doing the task. It is the decision, and checking what came out of it. For Dwarkesh the bottleneck is the compute poured into a single decision. For me it is my own attention. The mechanism strikes me as the same one, only the currency is different.

Evolution works in a surprisingly plain version, the one Dwarkesh puts in a footnote. He cites a study by Bloom and colleagues where management training alone raised company productivity by 17 percent, and observes that in a company of models such an upgrade could reach every copy at once. The way a change spreads looks similar here, because I edit one instruction file and every agent works from the new version the next time it runs. I am not claiming this buys me a 17 percent productivity gain. I am saying there is no transition period, no training session and no rollout meeting.

What is missing from that description with today's models

The author writes that in a company of models “There is no principal-agent problem wherein employees are optimizing for something other than Google’s bottom line, or simply lack the judgment needed to decide what matters most”. He does add in a footnote that the problem does not vanish, it relocates: between workers who suddenly know everything and shareholders who know about as much as they do today, which is close to nothing. Mine looks different again, simply because I do not have AGI. Dwarkesh is describing companies that already do. My agents are not optimising for something other than the company’s result, but they are capable of reporting a result they never verified. Those mistakes are getting rarer, yet the cost has still moved from policing intent to checking claims, and my scarcest resource is the attention and the time that checking takes. That is why every process here has a verification step and a defined moment of escalation to a human, which is precisely the loop I wrote about in July when covering Replit’s autonomous company pattern.

The second thing is the size of the firm. Dwarkesh leans on Coase and writes that as coordination inside a company gets cheaper, “the lower the intra-firm transaction costs, the larger the firms will grow”, while noting straight away that “it’s not inevitable that this ends with one gigafirm”, because internal planning still needs an outer loss function tied to the market through profits and losses. Here the mechanism confirms itself in a slightly different way. The boundary of the firm moves inward, because services and products we used to buy on the market we now make ourselves with AI. I mean lead generation tools, marketing services, the CRM, and we are already working on user support. The company grows in scope rather than in headcount, so measuring its size by the number of people would suggest it is shrinking. Headcount stops being a sensible measure in companies built around AI.

How close to a fully automatic company we are today

Sales is automated to a large degree. Generating and warming up leads has been fully automatic for many months. We replaced Pipedrive with our own CRM built around agents, which triages incoming enquiries and prepares quotes before anything reaches me. Marketing, search positioning included, is fully automated as well. A fair number of administrative functions now run practically by themselves.

Next in the queue are onboarding and user support, where we intend to replace an expensive Intercom with our own service system. Work is already under way and I hope to land it by the end of the year, though a lot is happening inside Element itself, which may push it out. The wish to replace Intercom with our own tool is not only about the size of the licence bill. The benefit of building it ourselves is that a support system sitting in the same place as the product code and the task queue can hand a ticket straight to implementation, instead of retyping it between people and tools. We have been developing the product itself in this mode for many months, which I wrote about in June in a piece about how Element is developing faster than ever before.

What Element clients get out of it

The first thing is price. We have never raised prices for our clients, and now I plan to go further and use the automation to bring prices down rather than up, which with rising costs is the ordinary reflex in SaaS. Automation cuts the part of the cost that turns into neither features nor safety, meaning the repeatable handling of a process. The quality of user support stays as high as we can make it.

The second is the ratio of cost to what the system can do. It follows from the price and from the pace at which we add features, and if you are comparing recruitment systems, that ratio is the number I would work out instead of the subscription price on its own. I put all of it together in a guide to ATS systems.

The third is how fast we react to a reported need for a change in the system. An agent picks up that report and passes it to implementation, so between the report and the start of the work we count minutes rather than weeks. I write “the start” deliberately, because the road to production still runs through automated tests, a code review done by a human and a staging server. Automation shortened the queue in front of the gate. It did not remove the gate, and I am not going to remove it. Day to day user support is a separate matter, still waiting its turn.

Why I treat this as an experiment

I am doing it because it absorbs me. I am learning things I could not do two years ago, going where most organisations have not gone yet, and collecting experience that cannot be bought as a course. Large companies have procedures, departments and people used to one way of working. I have a small team and I can rebuild a process without clearing it with anyone. That advantage is worth using while I still have it.

I also want to share how it turns out, including the parts that did not work, which is why I write pieces like this one. There is a straightforwardly commercial calculation in it too, because we want to keep developing the system and answering users immediately for as long as companies are recruiting, whether the recruitment market happens to be growing or shrinking.

What I am not going to automate

The decision stays with me, and so does the responsibility for it. Element processes hundreds of thousands of candidates’ personal records, so there has to be a person who answers for the fact that a given change went to production.

The product vision stays with me as well. I have a sense of how the technology is going to change the world, the labour market and recruitment in particular, and I am building something that will be ready for what is coming. That something is not Element. It is the tool that will replace Element once ATS systems are no longer needed.

If you are looking for a recruitment system and you count the ratio of cost to capability, take a look at Element.

A fully automatic company: frequently asked questions

Does a fully automatic company mean a company without people?

No. Agents run the operational processes, while a human picks the goals, makes the calls and answers for the result. In our case the decision, the responsibility for what reaches production and the product vision all stay with a person, and every process has a verification step and a defined point of escalation.

Do you need AGI for this to pay off?

No, and that is the practical point of the whole exercise. Dwarkesh’s essay describes companies made of AGI, while what works today is a weaker version of the same mechanisms. Even in that weaker version, a procedure written into a file copies in a second. The same procedure inside somebody’s head takes years to pass on, if it passes on at all.

What does automation change for clients of the system?

Three things. It cuts the part of the cost that produces neither features nor safety, which is what lets us plan lower prices instead of higher ones. It improves the ratio of cost to what the system can do, because features arrive faster. And it shortens the time between a reported need and the start of the work on it from weeks to minutes, without removing the tests and the human code review that stand in front of production.