Findem Studio is designed to be reached three ways: as its own destination, through the Findem platform that runs on Studio underneath, and from an external AI client such as Claude, connected over MCP. Those routes exist because the same agent has to reach three different kinds of user, and an agent that only reaches one of them is an agent most of the organisation never uses.

This page explains the access model and what each route is designed for. It is not a setup walkthrough, and it deliberately does not tell anyone where to log in: nothing published describes a first-run experience, and a page that invents one would be worse than a page that says so.

Key takeaways

• Three designed routes: Studio as its own destination, the Findem platform, and an external AI client over MCP.
• The routes are alternatives, not steps. An organisation is expected to use more than one.
• Which route matters most depends on who would use the agent daily, not on which route sounds most advanced.
• Findem Studio is the people intelligence layer the Findem platform runs on, not a separate product beside it.
• The Succession Planning agent is first out. Role Calibration, Hiring Manager Intake and Sourcing are described as coming later.
• Findem does not make employment decisions. Agent output is a recommendation subject to human review, and a person decides.
• Two of the three routes are designed to need nothing technical. The MCP route is the one built for engineers.

What is Findem Studio?

Findem Studio is people intelligence built for AI. It is designed to turn that intelligence into finished work you can trust, such as a succession plan, a market map, a benchmark, or an intake, produced and backed by evidence rather than left as raw material a person still has to assemble.

It is not a separate product sitting beside the Findem platform. The platform runs on Studio underneath, and Studio is also designed to be accessed directly or through a team’s own AI client. That is why access is described as three routes rather than one door.

Three things have to be in place before anyone acts on the output. The right intelligence before it starts: labeled data about people, companies, and the relationships between them, so the model reasons over the right material rather than whatever it found. The right method while it works: a defined approach from a named practitioner who reviewed the agent or from your own organisation, rather than one invented on the spot. The right checks before anyone acts: conclusions validated against the evidence, with the reasoning shown.

What does “agent” mean here, as opposed to a chatbot?

An agent carries out a defined task on its own, following a set process, and hands back finished work. A chatbot waits for your next question. That difference is what makes the access model a design decision rather than a detail.

A chat window only ever needs one door, because you go to it. An agent that actually does work has to reach people where that work already happens, which is why one route was never going to be enough.

If you have seen Glider’s own agentic AI interviews, the word means the same thing there: a process that runs end to end rather than a prompt waiting for input. The same pattern shows up in Glider’s AI Recruiter, a set of modular agents covering sourcing, screening, verification and coordination, deployable individually or together and integrating with an existing ATS rather than replacing it.

How do the three access routes compare?

They differ in who they are designed for, what they are designed to require, and what they cost in context switching.

None of the three are mutually exclusive. A staffing firm might use Studio directly for succession work on a small executive team while a separate RevOps group wires the same underlying agent into an internal reporting tool. The routes exist because different roles in the same organisation need different doors into the same work.

What is the direct route designed for?

Studio as its own destination takes the form of a standalone application, with the agents in one dedicated interface rather than embedded elsewhere.

It is designed for a recruiter or TA operator who wants a dedicated interface and does not want to think about where Studio sits relative to everything else. If your day already involves switching between several specialised tools, adding one dedicated to agent work is a small cost. The design intent is to provide the full experience without anything being translated or simplified for a host interface.

The tradeoff is that it is one more place to check. For a team that works inside a single system all day, that context switch has a real cost each time, even if it is small. This page does not describe a login flow or an initial user experience because none has been published. Inventing one would be the most damaging thing a page like this could do.

What is the platform route designed for?

Not going anywhere. The agents are designed to run inside the Findem platform a team already uses, because the platform runs on Studio underneath, and the output lands next to the data and workflows it is already connected to.

This suits teams that have built Findem into their daily rhythm and want agent output inside that rhythm rather than beside it. A TA leader who already reviews a Findem view every morning does not want a second place to look for agent results.

It is also designed to mean less training. If a team already knows how to navigate the platform, using an agent inside it asks them to learn one new capability rather than one new system. The trade-off is working within that surface rather than the standalone Studio one.

What is the MCP route designed for?

Findem’s MCPs. Studio’s agents are designed to be accessible through the protocol, allowing a team to call those agents and access the underlying intelligence through an AI client it already uses, such as Claude or another assistant, without requiring every recruiter to learn a new interface.

This is the most technical route and the one aimed at a RevOps, IT or data team rather than an individual recruiter. The point of it is that agent capability travels to wherever a team already does its AI work, instead of asking the team to travel to it.

If your organisation already has a pattern for connecting AI clients to internal data through REST APIs or similar protocols, this is the same shape of integration work applied to people data. The Model Context Protocol specification is the normative document to hand engineers, and its security section is worth reading before scoping anything, because it is explicit that descriptions of tool behaviour should be treated as untrusted unless they come from a trusted server.

One thing to be clear about, because the category has blurred it. Most vendors in this category have opened an MCP connection to their data, which makes a connection table stakes rather than a differentiator. Access is not intelligence, and a connection is not finished work. What matters underneath a connection is whether the data has been sorted and labeled, whether a method is applied, and whether anything checked the result. Findem’s own argument sits there: the world’s people data is an unsorted library with a billion books, everyone is handing AI a library card, and Findem built the catalog.

Which route is each kind of team designed around?

Start with who would use the agent day to day, not with which route sounds most advanced. The mapping the model implies:

1. A recruiter or TA operator as the primary user, who wants a dedicated interface with nothing competing for attention. The direct route is built for that.
2. A team that already uses the Findem platform for sourcing or people intelligence work. The platform route is designed so results appear alongside the data the team already trusts.
3. A technical team that wants agent capabilities inside tools it has already built, or an AI client such as Claude that calls agents directly. The MCP route is built for that, and it is the only one of the three that requires engineering.
4. Two of those scenarios applying at once. The routes are designed to coexist. Treating them as mutually exclusive would impose a constraint that the model itself does not.

What is announced, and what comes later?

The Succession Planning agent is first out. Role Calibration, Hiring Manager Intake and Sourcing agents are described as coming later, joining the Studio lineup as part of the ongoing roadmap.

If your first use case is one of those three, that is worth knowing before any planning is built around them. The preparation that is worth doing regardless is the part no vendor does for you: identifying which workflow you would apply an agent to, and getting the data behind it in order.

There are also three ways the model describes getting finished work out of Studio, and they map onto the access routes without being identical to them: a prebuilt agent, an agent you build using your own method, or Findem’s MCPs embedded in something you are already building.

Who reviews what an agent produces?

A person does. Findem does not make employment decisions. Agent output is a recommendation subject to human review, and a person decides.

This is an architecture question as much as a policy one, and it is the part most access discussions skip. Whichever route an organisation uses, somebody has to own the review step, and the route changes who that naturally is. The direct route puts the reviewer in front of the output immediately. The platform route puts it next to the rest of their work. The MCP route can quietly send agent output into an automated pipeline where nobody looks at it, which is the failure mode to design against before anything is built.

Two related boundaries are worth including in any rollout plan. Studio is designed to return finished work with evidence attached, not a score, a grade, a ranked list of people, or a prediction about anyone. No practitioner’s name is attached to output they have not reviewed, which matters if the methodology of a named consultant or your own organisation is encoded into an agent. 

The NIST AI Risk Management Framework, the voluntary US standard for building trustworthiness into AI systems, is a useful neutral reference when writing that review step into a process, particularly if a security or legal review is going to ask how oversight works.

Why does the access route matter as much as the agent?

Because the route decides whether the agent gets used at all. An agent buried in a system nobody opens daily sits idle no matter how good its reasoning is.

This is the same reason rules-based hiring automation succeeds or fails on where it runs rather than on what it does. A well-built process in the wrong place is a well-built process nobody triggers.

Three routes exist because the same agent has to reach a recruiter in a purpose-built surface, a TA leader inside a platform they already use, and a technical team inside their own tools, without asking any of the three to change how they work more than necessary. That principle is worth applying to any tool you evaluate, not only this one — the broader guide to AI recruiting covers how the same question plays out across screening, engagement and assessment.

What sits beside Studio in an existing stack?

The tools already running your funnel. An access model does not replace them, and nothing here should be scoped as though it might.

If your team already runs AI recruiting software for screening, assessment and interview logistics, that layer stays exactly where it is. Studio is positioned as the upstream planning and production work.

One boundary to state plainly, since Glider is publishing this. Glider partners with Findem, and the announced work combines Findem’s data labeling with Glider’s skills validation. That is a partnership between two companies, not one product: there is no confirmed direct technical integration between Findem Studio and Glider’s skills assessment platform or AI interviewing tools. If a workflow depends on assessment data flowing automatically between the two, plan for a manual step rather than assuming a pipeline exists.

FAQs