DocsSign inJoin the beta
All articles
New hire arrival

Can a new hire use the company's AI on day one?

A new hire needs neither months nor training on an assistant: their AI inherits their department's scope from the start. It is only ever as good as what that department bothered to write down.

By Alexis PratSeptember 8, 20265 min read
The short answer

Yes, once their read scope is set. Attaching someone to a department is immediate in managed mode, no invitation to accept, and the AI working for them inherits that scope at once: it reads the department's existing pages, no more, no less. What it actually knows depends on something the attachment does not manufacture: what that department had already bothered to write down.

What no CV ever brings

A new hire arrives with a skill the company went out and found on purpose. They arrive with none of the answers that only exist here: what gets granted without asking, what gets settled with a quick message rather than a form, whose desk a given question always lands on. The first weeks go into rediscovering each of these, one at a time, by interrupting someone who is busy.

A personal AI assistant changes none of that as long as it only knows what it has been told since it was opened, which is nothing about the company. It answers with a generality, or worse, it answers wrong with confidence - which costs more than no answer at all.

The question, then, is not whether AI can help a new hire. It is whether it has to relearn the company from nothing at every arrival, or whether it can already know - because the company already did.

Attaching someone is not teaching them

Attaching someone to your Kastel is not about teaching them the company. It is about giving them a read scope: the departments and documents they are allowed to read. That scope is the only thing deciding what gets served to them, and it applies the same way everywhere, in the console and through whichever AI they plug in. You never set an AI's rights, you set a person's, and the AI inherits them - the same principle behind context governance, applied on arrival rather than on departure.

In managed mode, adding a person asks for an email address and a role, nothing else, and it is immediate: no invitation to accept, no automatic email. The role - member, admin, auditor - says what they can administer, never what they can read. The gesture is described in the Invite your team guide.

What they can read depends on the department they are attached to, and that attachment previews before it applies: which pages become visible to them, which stay out of reach. Nothing gets built at that moment - the pages already exist, dated and owned by someone, since before their first day. Attaching a person manufactures no content; it opens a door onto what already existed.

The department's pages, already writtenThe scope attached to their responsibilityWhat their AI reads from day oneThe rest of the company, out of reach
A new arrival's scope is not built on their first day: it applies, at once, what their department had already written.

When the page falls short, knowing who to ask

A read scope grants access to what is written down. It does not say, when a page only half answers, who to ask for the rest - which is exactly what a new arrival never knows, for lack of time to learn who is who.

Your Kastel holds an answer here that no job description gives: who, in practice, wrote and kept a subject's pages up to date. These are counts, never a score, and they stay bounded to the read scope of whoever is asking - an AI working for a new hire learns nothing beyond what that person is themselves allowed to see.

Asked from the console or straight to a connected AI, "who owns this subject" replaces the reflex of a message sent into the void, hoping a busy colleague answers before the day is out. It names one person to ask, not a stack of documents to re-read alone.

One socket, not one integration per person

Once the scope is set, the AI itself still needs plugging in - whichever one the new hire already uses, or whichever the company hands them. MCP is a standardised power socket for AI: a universal port through which an AI tool reaches a company's context and tools. Kastel is an MCP server: it publishes your company's context on that socket. Any compatible AI connects to it, reads what it is allowed to, and acts.

That spares your IT team from integrating a new tool at every arrival: the socket is the same for everyone. And if that person prefers a different AI six months in, switching providers rebuilds nothing - unplugging one appliance and plugging in another on a standard wall socket.

Run the test before the real arrival

None of this needs a real hire to test. The core of Kastel installs free of charge on your own infrastructure, and you plug in your own AI keys. Add a fictitious person, attach them to an existing department, and look at what the preview shows before you apply anything: which pages would become visible, which would stay out of reach.

Then ask it the question a real new hire would ask on day one, and compare the answer to what an experienced colleague would say from memory. If the gap worries you, that is a signal about what your department has, or has not, bothered to write down - not about the tool reading it.

How many people does your company need to connect?

Every managed plan includes a number of seats, and the free core stays unlimited in self-host. See what matches the size of your team.

See plans and seats