The Automated Company, part 1: why we are building a company run by AI

2026-10-04

This is the first part of the series “The Automated Company”. In it, I want to show step by step how we are building a company at Element where automation does the routine work and people make the decisions, including the things that did not work the first time. I have already written that Element is building a fully automatic company and what our clients get out of it. In this series I will show what it looks like from the inside, and I am starting with the simplest question: why are we doing this at all? If you read Polish, there is also a Polish version of this article.

There are four reasons: a passion for technology, curiosity about where its limits lie today, a belief that the best way to learn is by building, and a very practical calculation, because automation lets us do more for our clients without raising costs.

Where we are starting from

Element is a small company. We have a product, a recruitment system used by HR departments and agencies, and alongside it I run training on the practical use of AI in companies. On top of that comes everything every small business owner knows: sales, proposals, invoices, the calendar, the inbox, marketing, customer support and hundreds of small tasks that will not do themselves.

I am the CEO and I am not a programmer, which is an important part of this story. I do not write code by hand, and yet today our company map has 39 projects and automations, 25 of which run every day. Some of them are big, like rewriting Element’s entire interface, where AI agents prepared 181 of the 182 changes in the code. Others are small things that save a dozen or so minutes a day, but every single day.

Passion and curiosity about the limits

I will start with the least business-like reason, because in my view it is the truest one. Technology simply fascinates me, and AI models are changing so fast that what was impossible a quarter ago works today and will be obvious a quarter from now. I want to see for myself where that limit really lies in practice. The only way I know to find out is to give AI real work in a real company and watch what comes of it.

Sometimes more comes of it than I expected. Sometimes an automation does something silly with great confidence, and it is exactly those moments that produce the most important rules, which I will write about in the next posts.

Building is the best way to learn

I can read a hundred articles about AI agents and still not know how they will behave on a Monday at eight in the morning, when a proposal has to go out to a client. The knowledge that really counts only comes from building: a specific process, specific data, a specific bug to fix.

I then share that knowledge at my AI training sessions. Participants get things I have tested myself: what works, what only looks good in a demo, and where AI needs a person more than you might think. In my training sessions I often say that my most valuable lessons came from automations that got something wrong, and this series is largely a record of exactly those lessons.

More for clients, without higher costs

There is also a purely practical reason. A small company has limited resources, while clients expect the same as they do from big vendors: quick answers, new features, up-to-date documentation and help when they need it. Automation lets us do more for them with fewer resources, without raising costs.

You can see it in the product. New Element features reach clients faster than ever before, there are far fewer support tickets, and churn, meaning clients leaving us, is going down. You can see it in daily work too: preparing a proposal, answering an inquiry or putting together a training document takes minutes today where it used to take hours.

What automation does on its own, and where a person decides

We expect automation to take routine work off our hands: collecting data, preparing texts, keeping track of deadlines, organizing information and checking that everything works. It should also speak up when something breaks and stay quiet when everything is fine.

Some of it runs completely on its own, including when it reaches out to the outside world. The best example is sales. Every day the system finds companies that are hiring right now, checks whether they are already in our CRM, and sends them a first message itself, followed a few days later by reminders. A sales bot carries those conversations forward on its own: it answers questions and concerns and gets back in touch after a few months. Automation also answers inquiries from the contact form on our website, invites people we have corresponded with to our newsletter, and updates selected parts of the website. I do not approve these messages one by one, and I do not have to.

Working on its own does not mean working without control, though. Each of these automations has limits written into its code: daily send limits per mailbox, only one first message to any given company, lists of blocked domains, and a six-month pause after three messages without a reply. Before the sales bot sends anything, its text is checked by an independent agent acting as a critic and by several mechanical tests, and any of them can stop the send. A separate automation checks every day that all the limits are being respected, and once a week another one rates the quality of a random sample of sent emails.

People stay in the loop where a mistake costs the most or where the relationship matters. When a company replies and the conversation gets specific, the automation prepares a draft reply, proposed meeting times or a proposal, and I send them. The same goes for training invoices, new issues of the newsletter, posts on this blog and replies from my own mailbox. An agent starts preparing a code fix only once I give the go-ahead, and merges it into the system only after a second approval.

I think the most important lesson of the whole project is about exactly this boundary. An automation can act on its own where we can describe up front what it must not do, and keep checking that it sticks to that. Where no such description is possible, a person makes the decision. I will show in detail how we build these boundaries in the next parts of the series.

What is coming in the next parts of the series

Foundations first, then increasingly specific automations. In the next posts I will cover, among other things:

the company map, which is where it is worth starting before you automate anything,
splitting work among AI models into supervisor, executor and critic roles,
company memory and one set of rules for all AI assistants,
gates for irreversible actions and an independent critic that checks an agent’s work,
specific automations: finding companies that are hiring right now, a sales bot with a human in the loop, sales proposals, training from calendar to invoice, and content marketing.

In part 2 I will start with the foundation, the company map: how to write down what a company is made of before automating anything in it.

By the way, this post, like the whole series, was made the same way: AI prepared the plan of topics, I add my own comment to each topic, and the draft is written by an agent that knows those comments and our rules. The last word before publication is mine.

Read more about what an ATS is and how Element works here.