Give Your Team an AI Coworker - Without Giving It the Keys

Summary

If people in your business keep interrupting the same few employees for answers, you probably do not have an AI problem. You have an access-to-information problem.

We gave our team an AI coworker inside the tools they already use. It can find answers in approved business systems, explain where those answers came from, and help turn a software issue into a reviewed next step.

The important part is what it cannot do: it does not quietly change production software, bypass permissions, or merge its own code. It helps the people responsible for the business move faster without taking the keys away from them.

The question we were actually trying to solve

A production leader needed a technical diagram that was buried somewhere in the business. The old answer would have involved calling a vendor or interrupting whoever happened to remember where the document lived. Instead, he asked in Teams and the system found the relevant source in a couple of minutes.

That moment was useful, but it was not the whole case for an AI coworker. The larger problem was that answers, permissions, and small software fixes were scattered across people and systems. The owner became the default permission broker, and plenty of little internal-tool problems never became a real project.

The useful first version was an assistant inside the communication tools employees already use. It could answer questions from real business systems, point to the source of an answer, draft a path forward, and turn a software problem into a reviewed pull request. It was deliberately not allowed to merge anything.

What we built

We built two agents around one human decision point.

1) The concierge lives where people already ask for help. It can search approved business systems through typed tools, answer questions, explain where the answer came from, and say when it does not know.

2) The builder can take a confirmed software problem, inspect a read-only copy of the relevant codebase, ask clarifying questions, work in a sandbox, run tests, and open a ready-for-review pull request.

It cannot merge the pull request. That was not an accident or a policy reminder somebody might ignore. It was structural.

The builder uses a non-admin identity, and the repository requires an approval it cannot provide. The human review gate is not a speed bump after the fact. It is part of the product.

The honest headline

The system has been useful, but it has also been humbling.

The first version made it possible to file and scope small internal-tool issues far faster than the old “someone should fix this” process. It also made clear that an AI which can read a codebase and write a plausible fix is not the same thing as an AI that has proven the fix is useful in the real business.

In a dated early process-review window, every builder-authored pull request contained at least one real blocker despite green CI. One issue made it from intake to merge with no human touch before the stricter verification gate was rebuilt, and the fix was inert because the original premise was wrong. That is not an argument against the system. It is the reason the system now requires stronger production evidence before it can open a pull request.

I would rather learn that lesson on a small internal fix than after a confident machine changes a business-critical workflow.

The part that actually matters: permissions

Most small companies already have a version of this problem. The people who know the answer are interrupted all day. The owner becomes a permission broker. Internal tools accumulate little defects because none of them are big enough to justify a formal project.

An AI coworker can help with that, but only if the permissions are real.

A chat allowlist is not enough. The agent needs to know who is asking, which underlying system that person is already allowed to use, and which actions still belong to a human. In our implementation, sensitive capabilities were restricted at the server side. The assistant was not trusted merely because it was in a familiar chat window.

That is less magical than “AI knows everything.” It is also much more useful.

What I would allow first

If I were starting this again in a small manufacturer or home-services company, I would start with four narrow jobs:

1) Answer questions from approved, read-only sources.

2) Show the source or explain the uncertainty.

3) Draft a structured next step for a person to review.

4) Collect requests that are not yet safe or supported, so the company can see what employees actually need.

That last one is underrated. A refusal is not necessarily a failure. If people keep asking the same unsupported question, you have found a gap in your systems, documentation, or permissions.

What should stay human

The uncomfortable answer is: more than the AI sales pitch suggests.

People should retain the authority to approve financial, customer-facing, personnel, security, and production-code changes. A system can prepare the work, point out the evidence, and make the human review much faster. It should not quietly turn a suggestion into a decision.

I am cautiously optimistic about this category, but I am not ready to call it autonomous business management. The more useful claim is simpler: it can give a small company a much better first pass at the work that currently dies in chat messages, spreadsheets, and somebody’s memory.

The lesson

The question is not whether a bounded system can help answer an ERP question or prepare a software change. In our case, it can, sometimes impressively.

The question is whether you have built the rails around it.

A useful AI coworker should make the company easier to run without making accountability harder to find. If the system cannot show its source, respect a permission boundary, admit uncertainty, and stop before the irreversible step, I would keep it in the lab.

But if it can do those things, you may have found a practical way to give employees faster access to the business without asking them to trust a black box.

Want to see the real system?

The next step is not to copy an abstract AI diagram. It is to look at one workflow your team already struggles to access, then decide what the assistant can read, what it can draft, and where a human still has to approve the next move.

See the AI Coworker use case or tell me about the workflow your team keeps asking people to explain.