Imagine hiring someone new and giving them almost no onboarding.
They don’t really know what their role is yet. They don’t know which systems they should be using, what information they’re allowed to access, which decisions they can make themselves or when they should ask someone for help. Every time you need something from them, you give them a very specific instruction and explain the background again.
“Can you check this account?”
“Can you summarise these notes?”
“Can you draft a reply to this customer?”
It would be a strange way to work with a person. They might complete each individual task perfectly, but you probably wouldn’t describe them as a functioning member of the team. They’re missing the context, access and boundaries that allow someone to actually take responsibility for a job.
And yet, that is still pretty close to how many of us use AI at work. We open ChatGPT or another AI tool, explain the situation, give it a task and take the output somewhere else. Then the next time we need help, we start again.
That works perfectly well for one-off tasks. But if we want AI to become something we can genuinely delegate ongoing work to, a good model and a clever prompt aren’t enough. It needs onboarding too!
A model is only the starting point
When someone joins a company, giving them a job title doesn’t suddenly make them useful. They also need to understand the company around that role.
They need access to the right tools. They need to know where information lives, what happened before they arrived, what they’re responsible for and where the limits of their authority sit.
AI has many of the same requirements.
On its own, an AI model doesn’t know what happened in your company yesterday. It doesn’t automatically have access to your CRM, inbox or internal tools. It doesn’t know which actions are safe to take, which require approval or which information is relevant to the job you want it to do.
Most AI tools solve that by making the human provide the missing pieces each time. We copy information into a chat, explain the background, ask for something and then move the result back into the system where the work actually lives.
Lobu takes a different approach. Instead of treating each AI interaction as a separate conversation, it provides the infrastructure around the agent that allows it to operate inside the context of a real company.
Give the AI access to the company around it
Lobu sits between AI agents and the systems a business already uses.
Through connectors, an agent can work with information from tools such as Gmail, Slack, GitHub and other business systems, even browsers and computers. Memory keeps useful facts, events and decisions available across sessions, while automations allow work to happen on a schedule or when something changes rather than only when someone remembers to open a chat and ask.
The important part is how these pieces work together.
Something can happen in a connected system, become part of the company’s context and then be used by an agent to understand what is going on. The agent can take an allowed action, prepare something for review or ask for approval, and what happens next can become part of that context again.
That turns AI from something you repeatedly brief into something that can work from a much more continuous understanding of the business.
Memory changes what you have to explain
One of the strangest things about using AI today is how temporary many interactions still feel. You can spend time explaining how your company works, correcting an answer or making an important decision, only to find yourself providing the same context again later.
Lobu is designed around durable organizational memory instead. It can retain relevant entities, facts, events and decisions across sessions, so agents don’t have to rely entirely on whatever happens to fit inside the current conversation.
That matters because company context rarely lives neatly in one place. A customer may appear in your CRM, email conversations, support tickets and upcoming meetings. The useful insight often comes from connecting those things, not from looking at one source in isolation.
An AI teammate should be able to work from that broader picture without relying on someone to manually assemble it every time.
Access should come with boundaries
Of course, onboarding someone properly doesn’t mean giving them access to everything.
A new employee gets the systems and permissions they need for their role, and different actions come with different levels of authority. Being able to read an account record doesn’t necessarily mean you should be able to change it. Preparing an email isn’t the same as being allowed to send it.
Lobu applies the same principle to AI.
The agent’s instructions are kept separate from the permissions around what it can actually access and do. Connectors, credentials, network access and actions can be governed independently, while sensitive actions can require approval.
This changes the conversation from simply asking “Can the AI do this?” to a much more useful question: “Should it be allowed to do this on its own?”
That distinction becomes especially important once AI starts doing more than answering questions.
Proactive doesn’t have to mean autonomous
Most AI interactions still begin with a human prompt. Lobu’s automation layer means an agent can also run work on a schedule or in response to an event. That could mean checking something regularly, preparing an update when new information appears or starting a workflow when a relevant event happens.
But proactive AI doesn’t have to mean handing over control. An agent can gather information, prepare work or move a workflow forward and still pause before a sensitive action so a person can review or approve it.
That middle ground is important. The goal isn’t an AI that either waits helplessly for instructions or operates completely independently. It’s an AI that understands what it can handle and where a human still needs to step in.
That shift from individual prompts to ongoing loops is something we’ve written about before in: The Agent Loop Is the New SaaS.
The AI doesn’t need to live in another app
There’s another practical difference in how Lobu is designed: The same agent can be used across team chat, a web app or other applications while keeping the same underlying memory, permissions and automations. Lobu can also connect with clients such as ChatGPT, Claude, Codex and other MCP-compatible tools.
So adopting an AI teammate doesn’t necessarily mean asking everyone to start working inside yet another standalone AI application.
The interface can change while the company context, permissions and workflows behind the agent stay consistent.
That might sound like a small technical distinction, but for teams it matters. Useful AI should fit into the way people already work rather than creating another place they have to remember to check.
What does onboarding an AI teammate actually mean?
Once you look at it this way, onboarding an AI isn’t really about writing a giant system prompt.
It means giving the agent a clear role, connecting the systems relevant to that role, making the right company context available, defining what it can access and deciding which actions it can take independently. Deciding what that role should actually be is a different challenge altogether. As we’ve written before, you don’t need to know how to build AI to know what it should do.
It also means giving it a way to act when something happens without requiring someone to start every interaction manually, while keeping approval points where human judgement still matters.
That is the infrastructure Lobu provides around the model. The model itself might change. The interface might change. You might use the agent through one tool today and another tomorrow. But the role, memory, connections, permissions and workflows can stay with it.
And that is really the point of the onboarding analogy.
When a new employee joins, you don’t make them useful by giving them increasingly detailed instructions every morning. You make them useful by giving them the context, access, responsibilities and boundaries they need to do the job.
If AI is going to become something we can genuinely delegate work to, we probably need to start treating its onboarding in much the same way.
Curious what this could look like for your team?
We can help you think through where an AI teammate could actually fit into your workflows, what context and systems it would need access to, and where human approval should stay in the loop.
Hi, I’m Emre 👋
I’m the founder of Lobu. We’re building AI teammates that understand their role, have the context they need and help move work forward without waiting for another prompt.
I started Lobu because I think AI should feel less like another tool you have to manage and more like a teammate you can actually delegate to.
See what we’re building at Lobu →Want to follow along with what we’re building? Connect with me