New to AI agents in HR? This post is part of our guide to AI HR agents — start there for the full picture, or keep reading for the deep dive.
If your intranet has a "corporate GPT" sitting in it that doesn't know the company's org chart, doesn't understand users' roles, and can't do anything beyond generating text — that isn't enterprise AI. It's ChatGPT with your logo on top.
Enterprise AI without context quickly turns into a pretty search box. It can write text, but it doesn't understand who reports to whom, what values the company holds, which processes are already running, and which actions are available to a specific user.
An enterprise agent's memory isn't about "remembering every conversation." It's about safe context: the org chart, roles, access settings, the history of public actions in the platform, and company rules. Without that, an agent can't give useful and safe recommendations.
In 2026 the bar for enterprise AI has risen. A real AI agent in the intranet isn't a single model behind a facade. It's six layers of infrastructure, and without any one of them the product slides back into "GPT wrapper" territory. Let me walk through each layer and what we're building in TeamEvo.
One Agent vs. a Zoo of Specialized Bots
The most common anti-pattern in 2025-era enterprise AI is the bot zoo. A bot for onboarding, a bot for the FAQ, a bot for submitting ideas, a bot for recognition (kudos), a bot for surveys. Each with its own interface, its own memory, its own set of rules.
The problem with the zoo: the user has to learn each bot from scratch. Which one takes which input, which one can do what, which one forgot what. Within two months a person remembers only one or two of the six and only ever goes to those.
The solution we chose: one agent with many tools. The agent is the same one, it has a single context, its memory is shared. And the specialized functions (company search, generating a thank-you, team stats, onboarding help) are tools the agent calls when needed.
From the user's point of view, it's a single chat window. From the infrastructure's point of view, it's a modular set of capabilities the agent applies depending on the request. This architecture is harder to build but far simpler to use. And within a year it becomes obvious that the zoo doesn't scale — while a single agent scales naturally: adding a new tool is cheaper than building yet another bot.
Multi-Provider LLM — Choosing the Model Per Space
The reality of 2026: there's no single model that fits everyone perfectly. And a product hard-wired to one model is at a serious disadvantage.
Different customers arrive with different requirements:
- Privacy-critical organizations (government bodies, banks, defense, fintech) require a locally hosted or self-hosted model and can't use foreign providers at all.
- International customers are comfortable using Claude or GPT-4, with GDPR requirements rather than national data-residency laws.
- Price-sensitive customers may opt for a cheaper model, especially for routine tasks (tag classification, generating short snippets).
- Enterprises often require a contract with a specific provider because they already have a DPA that their legal department has signed off on.
The architectural answer is a per-space LLM gateway. Each space (= each customer) picks its own set of models: "for recognition use model A, for classification use model B, for conversations use model C." The product code doesn't change because of this. Only the configuration does.
For development, this means: a single interface to the LLM ("generate text from this prompt, return JSON matching this schema"), and beneath that interface, drivers for different providers. OpenAI, Anthropic Claude, a self-hosted model via vLLM or Ollama, a regional provider — all identical as far as the business logic is concerned.
This isn't a "multi-provider" marketing gimmick. It's an operational necessity for compliance and cost. And it's exactly the layer you can't seriously work with enterprise customers without.
Memory Palace — What the Agent Remembers, What It Doesn't, and How It's Controlled
The most underrated part of enterprise AI. Most "AI assistants" treat each session as isolated — today you're one person, tomorrow another, and the agent remembers nothing. For everyday use, that kills the value.
We build memory as a multi-layered structure we internally call the Memory Palace. At the same time, the memory has to be governable. Employees need to understand what data is used, where it's stored, and what actions the agent can take on its own. For HR scenarios, one rule matters especially: the agent may recommend, but it must not covertly evaluate a person or make a personnel decision.
Layer 1 — the current conversation. The simplest and most standard. The last N turns in the current session. This exists in any chat interface.
Layer 2 — user memory. What the agent knows about you personally: your role, department, preferences, interaction history. "You prefer concise answers," "you were recently promoted," "you regularly thank colleagues in marketing." This memory personalizes the conversation and accumulates over time.
Layer 3 — team memory. Who's on your team, who's working on what, what events have happened over recent weeks. When you ask "help me prep for a 1:1 with Anna," the agent knows Anna reports to you, that you spoke with her two weeks ago, and that a question about her development was left open in that meeting.
Layer 4 — company memory. Values, org chart, processes, policies. This is shared space memory that the HR team shapes and updates. The agent uses it when corporate context is needed: "how do we usually reward initiative," "who's responsible for compliance," "what are our leave rules."
A fundamental point: isolation between layers. One manager's team memory doesn't leak into another's team. User memory is visible only to that user and never appears in any shared summary. Company memory is shared but de-identified. This is the compliance boundary, without which a Memory Palace turns into a leak risk.
And a second fundamental point: transparency for the user. In their profile settings, every employee can see what the agent remembers about them and delete any record. This isn't a "behind-the-scenes" feature; it's a baseline requirement of data-protection regulation as applied to ML systems.
Tool Store — What the Agent Can Do, Not Just Say
A good AI agent doesn't just respond with text — it performs actions at your request. That's what separates an "assistant" from a "reference book."
What we call tools:
- Company search. The agent can find a colleague, a document, a policy, an idea.
- Reading context. The agent knows the org chart, sees the recognition gap across the team, reads recent interactions.
- Writing actions. It can prepare a draft to send, can publish (with your confirmation), can create a calendar event.
- External integrations. Connected to your ITSM, CRM, or task tracker, it can create a ticket or find a task.
Examples of real requests that flow through tools:
- "Help me write a thank-you for Anna for yesterday's review." — The agent reads the context (who Anna is, what happened yesterday), generates a draft, shows it to you, waits for confirmation, and sends it.
- "Pull up the engagement report for last quarter." — The agent calls the analytics API and formats the result.
- "Who haven't I thanked in a while?" — The agent reads the manager dashboard and returns a list of blind spots.
- "Find a colleague in marketing who works with the product team." — The agent goes to the org chart and the interaction graph by tags.
The Tool Store is built so that a space admin can configure which tools are available to the agent. You can disable "writing actions" entirely (for a read-only mode). You can connect your own tool via API (a corporate CRM, for example). This gives the customer control over what the AI can and can't do.
And a fundamental point: every action that affects people requires the user's confirmation. The agent prepares a thank-you — it sends only after your "yes." The agent creates a feed post — it publishes only after confirmation. This isn't a technical limiter, it's an ethical boundary we hold deliberately.
Autonomous Agents — Where We're Headed
In 2026, enterprise AI mostly works synchronously: you ask, it answers; you request, it does. The next step is autonomous, asynchronous agents that perform tasks in the background.
Where this is already visible:
- "Prepare a draft performance review for the team for next quarter." — The agent gathers data, formats a draft, and a day later drops it into your intranet: "here, take a look."
- "Watch for blind spots and remind me weekly." — A background task that sends you a compact summary once a week.
- "If someone on the team shows a quiet-quitting signal, let me know right away." — Event-driven monitoring with proactive notification.
This is exactly the shift happening before our eyes. From "AI as an answer" to "AI as a task executor."
A boundary we hold deliberately: AI does the preparatory work, humans make the final decisions about people. Performance review — AI prepares the draft, a human edits and publishes. Recognition — AI suggests options, a human chooses and confirms the send. No "AI fired someone," "AI cut a salary," "AI decided on a promotion."
The roadmap here is gradually expanding trust. First the AI handles simple preparatory tasks. If those prove reliable, we give it bigger ones. This isn't "give the AI everything at once" — it's an incremental path where every step is verified.
Prompt Registry — How We Manage Thousands of Prompts
The hidden infrastructure without which everything above turns into unmanageable chaos.
Our product has dozens of AI features: AI Drafter, a brainstorm agent, a news digest, idea-tag classification, topic classification for engagement intelligence, birthday greetings, sentiment analysis. Each uses its own prompt. In reality, several variants of the prompt per feature: for different languages, different contexts, different model versions.
If you store prompts in code, you quickly hit a problem:
- You want to change a prompt — you need a code release.
- The prompt isn't localized — you have to copy and maintain it by hand.
- The prompt gives a bad answer — you can't quickly run an A/B test.
- A customer wants to tune the tone to their culture — impossible without a fork.
The Prompt Registry is an internal service that stores all prompts in a database with versioning, localization, a JSON Schema for response validation, and the ability to override per space.
How it works in practice:
- Each AI feature asks the Registry: "give me prompt
recognition.draft.v1in languageenfor space X." - If space X has a custom override of that prompt, that one is returned. If not, the default is.
- When the model generates a response, the result is validated against the JSON Schema — if the response doesn't match, the system automatically regenerates or substitutes a fallback.
- Any prompt change is a new version in the Registry, not a code release. You can roll it back in five minutes if something breaks.
This part of the architecture is invisible to the user, but it's exactly what makes AI features manageable in production. Without a Prompt Registry, an AI product becomes a mush of hardcoded strings that everyone's afraid to touch.
The Bottom Line
A 2026 enterprise AI agent is not a "GPT wrapper." It's six layers of infrastructure, each of which matters:
- One agent, not a bot zoo. A single window, shared memory, tools instead of separate interfaces.
- Multi-provider LLM with per-space selection. Compliance and cost for different customers.
- Memory Palace. Memory on four levels (conversation / user / team / company) with isolation and user control.
- Tool Store. It doesn't just "respond," it acts — with mandatory confirmation for actions that affect people.
- Autonomous agents. A gradual shift from a synchronous assistant to an asynchronous executor.
- Prompt Registry. Managing tens of thousands of prompts in production without chaos.
Most "AI in HR" products from 2025 had at most one or two of these layers. In 2026 that's no longer enough. If you're choosing an AI tool for your intranet, ask the vendor about each of the six — and you'll quickly separate the serious products from the "ChatGPT wrappers with a logo on top."
Next week: surveys. Pulse vs. annual, conversational surveys, lifecycle surveys, k≥5 anonymity as a technology rather than a slogan.
If you'd like an extended demo of the AI agent with a breakdown of all six layers on our real system, follow the link in the card.
Read next
AI Onboarding: The 14 Days That Decide Whether a New Hire Stays Six Months or Leaves
A classic corporate course is a PDF, a video, and a quiz nobody remembers a week later. Here's how we build an adaptive 14-day journey instead of yet another learning system.
Listen to Employees, Don't Just Count Surveys: The Shift to Engagement Signals
The annual survey is a depth sounder that touches bottom once a year. Here's how signals from six sources combine into a living picture of engagement, and why "What We Heard" is the most important page in your intranet.
Engagement Surveys: Why It's Time to Retire the Annual Check-In
Asking 800 people "how's it going?" once a year means getting the answer two weeks after they started feeling bad. Here's how pulse surveys, AI interviews, and lifecycle surveys replace the annual check-in.
