Ask a support lead where a customer's renewal actually stands and the honest answer is "give me ten minutes." The contract terms are in the CPQ tool, the last support thread is in the ticketing system, the usage numbers are in an internal admin console, and none of the three have a shared API or a shared login. Enterprise search tools solve this beautifully when every source is indexed and API-reachable. Most internal systems are neither—they're a search box behind SSO, rendering results as HTML for a person to read, not a machine to query.
Why Internal Search Doesn't Have One API
The tools that make up a company's real knowledge base—ticket systems, admin panels, wikis, vendor portals, internal ERPs—were built for employees clicking around, not for programmatic retrieval. Some expose a REST API for a subset of what the UI can do; most expose none at all. Wiring a direct integration to each one means maintaining N different auth flows and N different schemas, and the list of systems never stays fixed long enough to finish. The search box already works. What's missing is a reliable way to drive it on someone's behalf and get a structured answer back.
One Identity Per System, One Session Per Query
That's a login problem before it's a search problem. Each internal system gets its own identity—its credentials and saved session state, created once and referenced by ID everywhere else:
const zendeskIdentity = await anchorClient.identities.create({
source: 'https://acme.zendesk.com',
name: 'Support Search - Zendesk',
credentials: [{
type: 'username_password',
username: process.env.ZENDESK_USER,
password: process.env.ZENDESK_PASS,
}],
});
const session = await anchorClient.sessions.create({
session: { tags: ['internal-search', 'zendesk', 'ticket-4521'] },
identities: [{ id: zendeskIdentity.id }],
});
// Session opens already authenticated against Zendesk.The automation code never touches a password, and the session's tags mean a support engineer—or a compliance review—can later pull up every session that ran a given search, against which system, for which ticket.
Fanning a Single Query Out Across Systems
A real internal search rarely stops at one destination. The same customer name needs to be checked against the CRM, the billing console, and the support desk at once, and waiting for each in turn is the slow part. Since each system needs its own identity, the fan-out is a set of concurrent session creations rather than one uniform batch:
const targets = [
{ system: 'zendesk', identityId: zendeskIdentity.id },
{ system: 'salesforce', identityId: salesforceIdentity.id },
{ system: 'billing-console', identityId: billingIdentity.id },
];
const sessions = await Promise.all(targets.map(t =>
anchorClient.sessions.create({
session: { tags: ['internal-search', 'acme-corp', t.system] },
identities: [{ id: t.identityId }],
})
));Three lookups that used to happen one browser tab at a time now run concurrently, each under the identity that belongs to its system, each tagged to the same search request so the run can be traced later.
Turning Search Results Into a Structured Answer
The last step is the one a person actually wants: not three open browser tabs, but one merged answer. agent.task() can run against each already-authenticated session with a schema for what to pull back, so "search for this customer" returns fields instead of a page render:
const results = await Promise.all(sessions.map((session, i) =>
anchorClient.agent.task(
`Search for the customer "Acme Corp" and return the latest status`,
{ taskOptions: { sessionId: session.id, outputSchema: zodToJsonSchema(StatusSchema) } }
).then(r => ({ system: targets[i].system, ...r }))
));
// [{ system: "zendesk", status: "Open", priority: "High" },
// { system: "salesforce", status: "Renewal - Stage 3" },
// { system: "billing-console", status: "Current, no past due" }]The three results—CRM record, billing status, open ticket—come back as one JSON array instead of three browser tabs someone has to read by hand.
Search Infrastructure, Not Another Integration
None of this requires the internal systems to change. It's the same search box, the same login a person already has standing access to, run under an identity a security review can trace and a session a compliance audit can replay. If your team is stitching together internal search across systems that were never meant to talk to each other, that's the problem Anchor is built to remove. Get an API key and point your first batch session at the internal tools your team searches every day.
