Skip to content

Blog

Why We Stopped Using AI as a Tool and Started Building an Environment for It

Why We Stopped Using AI as a Tool

For a long time, we used AI exactly like most companies: as a very intelligent tool standing next to the real work.

You copied from CRM, Jira, email, and Slack. Packed it into a prompt. Hoped the model would piece it together. Sometimes it worked. More often you had to fix it, because AI answered the question you asked, not the one you meant - because it didn't know what you knew.

AI worked well as long as the human was the middleware.


This is not a model problem. It's a problem of where knowledge lives inside a company.

Who the client is. What they bought. What we agreed on three months ago. Why we made a certain decision. What we already tried. Who is responsible.

When an agent couldn't answer a simple question about a client, we often discovered that a human would have had to search for that answer in four different places too. AI just made the existing organizational problem more visible.


At some point we stopped asking how to write better prompts. We started asking what an agent needs to do the same work as a human.

Three things emerge.

Context. The agent needs to know - who the client is, what was agreed, what the project scope is, what has already been tried.

Capabilities. Not just reading, but performing operations on real data. Creating tasks, sending drafts, updating statuses.

Permissions and human review. An agent shouldn't just get an admin token and start firing API calls with the enthusiasm of an intern on a Friday afternoon. Some actions require human approval. That's not a limitation - it's part of the design.

Only when all three are in place does the agent stop being a chatbot with internet access and start being a participant in the process.

What an agent needs to work

In our case, these three elements are handled by specific layers.

Khirby is the customer context - who, what was agreed, when, what's open, communication history.

Pokelo is the project and company knowledge context - decisions, documentation, how and why we built something.

MCP and Skills are the interface through which the agent can use both and act.

An example from our work: a client writes requesting an additional data export. The agent checks communication history in Khirby, finds previous agreements, checks the project scope and technical decisions in Pokelo. If the feature wasn't in scope, it drafts a response and creates a task for change estimation.

None of these steps require pasting context into a prompt.

Example agent workflow

For companies that grow faster than their processes - this isn't a convenience. It changes how much one person can handle without losing quality.

That's why we don't want to build another SaaS with a "Generate with AI" button.

We're building an environment where humans and agents work on the same company context. The human uses the interface. The agent uses MCP and Skills. Both see the same facts, operate on the same processes, and are subject to the same rules.

AI stops being a tool you have to explain the company to every single time.

It becomes a participant in the system.

Want to fix one concrete process?

We start with a conversation about data, context, and where AI can actually help — not another chat window beside the company.

We reply within one business day · office@bearly.pro

Blog →