How We Accidentally Started Building a Human-Agent Company

We didn't plan this.

There was no meeting where someone said: from today, we're building an agent-based organization. We didn't draw up a three-year AI transformation roadmap or sketch out a target company architecture. Specialized agents simply started appearing in different parts of the business.

One knows a specific project inside out. Another specializes in a particular technology. On the growth side, there's an agent analyzing Google Ads, next to it an SEO agent, and another one handling e-commerce. Each was built for a different reason, by different people. Not according to some master plan - just wherever someone understood a problem well enough to know what they needed from a system like that. And that's probably why it took me a while to see what was actually happening. At some point it hit me: our company is starting to have more specialists than employees. Not in an accounting sense. An agent isn't an employee, and I'm not going to pretend it is.

It's about roles.

For years, the number of specializations a company could realistically develop was directly tied to the number of people. If we wanted to be stronger in a particular technology - we needed someone who knew it well. If we wanted to grow our SEO capabilities - we needed an SEO specialist. More thorough ad analysis meant more hours spent checking multiple systems, comparing data, and remembering why we made a particular decision two weeks ago. We still need people with diverse skills. That hasn't changed. Something else has.

A good specialist can now build an additional layer of expertise around themselves. A developer can have an agent that knows one specific project and another that specializes in the technology they work with. A growth lead can work alongside an Ads agent, an SEO agent, and an e-commerce agent. A designer might eventually have a system next to them that monitors live sites, collects data, tracks UX changes, and surfaces decisions made months earlier.

This doesn't make people less necessary. It just means they no longer have to do everything alone.

For a long time, we just used AI

I worked exactly the way most people do for a long time.

I had a problem, so I opened a model. Described the situation, pasted in the data, got an answer. Sometimes a great one. Sometimes mediocre. Sometimes highly convincing and completely wrong. Afterwards I'd close the chat and get back to work.

AI was a good tool, but the real context always stayed on my side. I was the one who remembered what happened a week ago. I knew why we'd changed something. I remembered that we'd already tried a similar idea and what came of it. Every new conversation meant explaining all over again what the company does, how the project works, what matters, and what shouldn't be touched. You can work faster that way, but you don't build organizational memory like that.

The first real shift came when we stopped starting every conversation from scratch. Instead of general-purpose AI, specialized roles began to emerge.

• Not a coding agent, but an agent that knows a specific project.
• Not a marketing AI, but a system responsible for Google Ads.
• Not an SEO chatbot, but an agent with its own data sources, memory, and a clearly defined scope of work.

That's when AI stopped being just a tool you fire up when you need something. It started getting a permanent place in how the company operates.

The model is probably the least interesting part of an agent

It's easy to build something that looks like an agent today. A model, a good prompt, a few tools, a simple interface. But the longer we build them, the less interested I am in the model itself. One system might run on Claude, another on ChatGPT or DeepSeek. A year from now, some of them will probably be running on something entirely different.

You can always swap out the model. What's much harder to build is everything around it - the role, context, knowledge, memory, tools, operating principles, constraints, and the history of past decisions. Our frameworks already include a ready-made knowledge layer. It collects and organizes project information, with data flowing into a shared database. This means a project can have its own knowledge layer. An agent can draw from it, and later you can plug in another specialist with a completely different role into the same context. One knows the project. Another knows the technology better. A third might eventually handle quality, security, or documentation. You don't have to start from a blank window every time, re-explaining the entire world from scratch.

To me, that matters far more than the name of the model that happens to be running underneath.

The company is developing a second layer

Today I see our organization roughly like this:

                         GRUPA INSIGHT

                            PEOPLE
                               │
            ┌──────────────────┼──────────────────┐
            │                  │                  │
            ▼                  ▼                  ▼

       DEVELOPMENT           GROWTH           DESIGN / UX

        person               person              person
          +                     +                  +
   project agents          Ads Agent           UX Agent
   technology agents       SEO Agent           next phase
                           E-commerce Agent

            │                  │                  │
            └──────────────────┼──────────────────┘
                               ▼

                  SECOND ORGANIZATIONAL LAYER

                  knowledge • memory • tools
                  decisions • history • outcomes

Not all of these systems are connected through a single shared memory. And they shouldn't be. An agent that knows a project's codebase doesn't need access to advertising data. The Ads system doesn't need to know the application architecture. But the pattern keeps repeating.

• A person has their own digital specialists.
• A project has its own knowledge.
• An entire area of the company can have a system that watches over it continuously.

And only now are we getting to the really interesting problem - how to organize all these roles.

We saw it most clearly when building the Ads agent

At first the task seemed simple. The system was supposed to analyze campaigns and draw conclusions. But the analysis itself quickly turned out to be the least interesting part. The agent needed to know which company it was working for. Know previous recommendations. Remember what had been approved, what rejected, and what already implemented. It had to work with multiple data sources and notice when those sources told completely different stories.

If Google Ads shows one picture and GA4 shows something entirely different - it can't just pick the number that best fits its narrative. It has to notice the problem first and understand what it means. Sometimes it needs to conclude that based on available data, it shouldn't be making a particular decision at all. So a simple idea for an ad-analysis system turned into a much larger architecture.

In broad strokes, it looks like this:

                        SINGLE AGENT

                      CONTEXT BOOTSTRAP
                              ↓
                        AGENT PLANNER
                              ↓
                          TOOL LAYER
                              ↓
                      CONFIDENCE ENGINE
                              ↓
                     CAPABILITY POLICY
                              ↓
                       REASONING LOOP
                              ↓
                        ACTION ENGINE
                              ↓
                 DETERMINISTIC GUARDRAILS
                              ↓
                     HUMAN IN THE LOOP
                              ↓
                           OUTCOME
                              ↓
                            MEMORY
                              ↺

The model is just one piece of this puzzle. Everything else determines whether you're dealing with a chatbot or a system you can entrust with real responsibility. The agent first needs to know where it works. A person doesn't start each day by re-learning the company from scratch. They remember clients, know the project history, understand why a particular decision was made a week ago. An agent without context has none of that.

That's why before doing any real work, it loads knowledge about the environment it operates in. For the Ads system, that means account information, business context, previous reports, and recommendation history. A project agent needs something entirely different - architecture, documentation, decision history, system-specific rules. This isn't the most impressive part of the whole setup. It's much easier to demo a model that answers questions instantly. But without this layer, every agent is just another consultant you have to brief from scratch every morning.

Then come tools and planning. A traditional script gets an instruction - fetch this data, calculate these metrics, generate a report. An agent gets a problem. If something looks wrong at the campaign level, it can dig deeper. Check keywords, then search terms, compare Ads with Analytics, look at Search Console, check whether a similar problem has come up before. It's not about pulling everything. It's about gathering the evidence needed for a specific situation. Only then can you talk about reasoning.

A good agent also needs to know how to say: I don't know

This is one of the things I missed most in early AI systems. Models are very good at answering. They're much worse at stopping at the right moment. With incomplete data, an agent can still spot obvious budget waste or a clear problem. But it shouldn't pretend it can reliably forecast sales. That's why our systems include confidence and capability policy layers. The agent doesn't just assess how sure it is of its answer. It also needs to know where the uncertainty comes from and what it's actually allowed to do given the data quality. It's a subtle but important distinction. Telling the model to be careful isn't enough. If something truly shouldn't happen - code should stop it, not a prompt. Hence the deterministic guardrails and the human who still approves or rejects every action.

Autonomy in itself isn't the goal for me - better company performance is.

A recommendation needs its own history

A traditional report has a short shelf life. An email arrives, we read it, maybe we act on it. A week later, the next one shows up. After a month, hardly anyone remembers exactly why we cut the budget, what the data looked like at the time, or whether the results matched expectations.

An agent shouldn't work that way. A recommendation has its own lifecycle. It can be submitted, approved, rejected, or deferred. Later it may come back for reassessment. Sometimes it gets withdrawn. That's why our system includes statuses like REASSESS and WITHDRAWN.

What interests me most is the moment when an agent revisits its own earlier conclusion and determines that it made sense two weeks ago, but new data has changed the picture. Or the opposite - it still stands behind it. A company doesn't operate in a single prompt. It operates through decisions, their consequences, and subsequent decisions made in light of what happened before. If an agent is going to be part of an organization, it needs its own history.

Then SEO appeared alongside Ads

And that's when things got really interesting. When only the Ads agent was running, you could still treat it as a standalone specialization. Now there's an SEO agent working next to it. And an e-commerce agent too. Each looks at a different slice of the same business.

• AI Ads sees campaigns, costs, queries, and conversions.
• AI SEO monitors visibility, site structure, content, technical issues, and Search Console signals.
• AI E-commerce looks at the product range, categories, user behavior, and sales.

It quickly becomes clear that these worlds can't really be separated.

A topic that performs poorly in ads might be strategically important for SEO. Campaign data can reveal which messages actually resonate with people. SEO might spot a shift in demand. E-commerce might show that traffic one system dismissed as weak is actually driving sales through a different path. So we don't need a single super-agent pretending to be an expert at everything - we need different specialists.

But at some point, the specialists alone aren't enough either, because someone has to see the full picture. If AI Ads recommends cutting the budget, AI SEO sees a strategically important topic, and AI E-commerce notices that users in that segment have a longer path to purchase - three separate reports won't do. You need a layer that recognizes a conflict has just emerged.

In our setup, this role is starting to be filled by the Orchestrator. It's not meant to be yet another Ads, SEO, or e-commerce specialist. Its job isn't to overrule the other agents. It oversees the entire process - but it knows which agent should handle a given problem. It can pass along context gathered by another specialist. When it sees contradictory recommendations, it doesn't automatically pick one. It gathers evidence, identifies gaps, and decides whether what's needed is another analysis, an experiment, or a human decision.

This is where something that actually resembles an organization starts to take shape. Specialists look at the business from their own angles. The Orchestrator makes sure they don't work as if the others don't exist. Underneath them sits a shared evidence and memory layer. That doesn't mean every agent sees everything. Different roles still have different access levels and different scopes of responsibility. The point is something else.

When two systems reach different conclusions, the organization should know why they differ. The Orchestrator's job is to turn that disagreement into a decision process - not three more reports to read.

Something similar is happening in development

Development agents have different goals, but the pattern is the same. We have systems built for specific projects. They have their own knowledge layers and don't start from a blank context. Information collected by the framework flows into a database and becomes the foundation for further specializations.

One agent might know a project well. Another might know a specific technology. Over time, additional roles may appear alongside them - quality, security, documentation. We don't want to produce agents just because we can.

An agent makes sense when there's a persistent problem. Repetitive work. Large amounts of context. Multiple data sources. The need to remember past decisions. Or an area that a person simply can't monitor around the clock.

The next natural area is UX

I don't mean an agent that designs websites by itself. That would be the least interesting application. What's far more compelling is a specialist working alongside a designer. It can know the project and remember earlier decisions. Analyze a live site, pick up signals, flag inconsistencies, track solutions appearing in other good products. It might spot an area worth testing. Remind the team that a similar idea was once rejected. Surface something from the data that the designer didn't have time to monitor regularly.

The designer still designs. They're the one who understands the brand and sees the big picture. But they don't have to be the only person who remembers everything, watches everything, and keeps track of everything. And this is where I see the most important shift.

A human-agent company isn't about agents doing everything. It's about people no longer being alone in their specializations.

Headcount no longer describes all of a company's capabilities

Grupa Insight has offered a wide range of services for years. Software. E-commerce. SEO. Ads. UX. Design. AI. For an outside observer, the natural question is how a company of this size can genuinely develop so many specializations. Until recently, the answer was straightforward. Today, however, the breadth of a company's expertise is no longer determined solely by the number of people on the team. The systems and digital specialists built around their work matter increasingly.

A good developer doesn't become less essential because they have an agent that knows their project. They simply stop wasting time on constantly rebuilding context.

An SEO specialist doesn't disappear because an SEO agent exists. They can spend less time collecting data and more on the things that truly need their brain.

A designer doesn't become redundant because a UX agent might appear alongside them. They get more time for the most important part of their job - making good decisions.

AI doesn't have to shrink the team. It can expand the number of specializations available to the same team.

A company of a dozen or so people can start operating as if an additional layer of highly focused experts were working alongside them. Not people pretending to be machines. Not machines pretending to be people. Simply new roles.

Maybe this is what a human-agent company looks like

I don't know yet whether this name will stick. For now, it describes well what I see. A company made up of people and a second layer of specialized systems. Developers have their own digital specialists. Projects have their own knowledge. Marketing has agents monitoring different areas. E-commerce has its own system. Over time, a similar layer will appear around UX and probably other parts of the organization too. Each agent has a different role, different context, different tools, and different permissions.

This is the least important part. Models will change. Roles, knowledge, memory, and process will remain. And the people who understand why these systems exist in the first place will still be the most important part of the organization. There's been a lot of talk in recent years about how many people AI will replace. That question interests me less and less.

What I find far more interesting is what happens to a company where every good specialist can build their own team of digital specialists around themselves.

I think we're just starting to find out. Not through presentations and not through theory. We simply realized one day that our company was starting to have more specialists than employees.