Guild supports custom REST/HTTP endpoint registration for internal APIs. You configure the endpoint URL, authentication method, and response shaping.
Guild Works with Your Stack: Pre-Built Integrations, Custom APIs, & an Open-Source SDK
The Problem Nobody Talks About
Here's a story we've heard more than once.
An engineering team has 15 tools connected to internal services — project management, monitoring, documentation, chat, and custom resources. The agents work. Sort of. But there's no visibility into which agent connects to which server. And tokens are shared across agents, so when something goes wrong — and it does — nobody can trace who did what.
There's no rate limiting.
No audit trail.
No way to revoke access to one agent without breaking all of them.
So, the team builds an internal gateway. A custom service just to manage access to other services. Months of engineering time. Infrastructure that has to be maintained, monitored, and explained to every new engineer who asks why it exists.
They'd happily retire it if something else handled it.
This is the dirty secret of agent extensibility: connecting agents to tools is easy. Connecting agents to tools safely — with scoped credentials, audit logging, and policies that don't require a homegrown gateway — is the hard part.
And it's the part most platforms ignore.
Every engineering team has internal APIs, custom services, and tools that no agent platform natively supports. The question isn't whether you need custom integrations. It's whether you can add them without building your own governance layer from scratch.
What "Bring Your Own Integration" Actually Means
BYOI isn't a feature. It's a design philosophy.
Most AI agent platforms give you a fixed list of integrations. Need something that's not on the list? Write a wrapper. Manage your own auth, and hope nothing breaks.
Guild works differently. The platform supports three layers of extensibility — and every layer runs through the same control plane.
Layer 1: Pre-built service integrations. GitHub, Slack, Jira, New Relic, Confluence, Figma, and more. One-click setup. Auth handled at the account level — credentials are configured once by an admin, and every agent that needs the service automatically gets scoped access.
Layer 2: Community-built integrations. Integrations published by other Guild teams, shared to the Agent Hub. Fork them, install them into your workspace, or publish your own back. Every community integration runs through the same credential and policy boundary as a first-party one — nothing gets a shortcut.
Layer 3: Your internal custom integrations. For the APIs that only your team has — internal deployment services, proprietary data pipelines, legacy endpoints that will never get packaged. Register any REST/HTTP endpoint as an agent tool, configure auth, shape the response. Done.
The key: all three layers are governed in the same way. Prebuilt integration and same-scoped credentials. Same audit trail. Same rate limiting. Same policies. There's no second-class integration on Guild.
Permission Policies: governance at the tool level
This is the part most platforms skip.
When you grant an agent a tool, Guild doesn't just check "can this agent call GitHub?" — it checks which GitHub calls, on which repos, with what scope. Permission Policies live at the control plane, not in agent code, and they apply uniformly across all three integration layers.
That means a freshly forked community agent can't quietly expand its access. A new custom endpoint can't bypass rate limiting. And when something goes wrong — a deleted issue, a leaked secret, a misfired message — there's one audit trail, one policy to change, one place to look.
Here's what scoped tool access looks like in practice:
TypeScript
1import { pick, userInterfaceTools } from "@guildai/agents-sdk"2import { gitHubTools } from "@guildai-services/guildai~github"3import { slackTools } from "@guildai-services/guildai~slack"4 5export default agent({6 description: "Reviews PRs and posts summaries to Slack",7 inputSchema: z.object({ prUrl: z.string() }),8 outputSchema: z.object({ summary: z.string(), posted: z.boolean() }),9 tools: {10 ...userInterfaceTools,11 ...pick(gitHubTools, [12 "github_repos_get",13 "github_pulls_list",14 "github_issues_create_comment",15 ]),16 ...pick(slackTools, ["slack_send_message"]),17 },18})
The agent gets three GitHub tools and one Slack tool. Not the entire service. Not "access to everything." The specific tools it needs, nothing more. That's governance at the code level.
Custom APIs: Register Anything as a Tool
Not everything speaks MCP. Not everything needs to.
Most companies have hundreds of internal REST APIs. Custom deployment services, internal data pipelines, proprietary analytics endpoints, and legacy systems that will never get an MCP server. Waiting for universal MCP adoption isn't a strategy.
Guild lets you register any REST/HTTP endpoint as an agent tool:
- Point to the endpoint. URL, method, expected request/response format. Just upload your OpenAPI definition.
- Configure authentication. API key, OAuth, custom headers — whatever the endpoint requires.
- Shape the response. Control what comes back to the LLM's context window. Strip noise. Keep the signal.
- Use it like any other tool. Once registered, agents are called the same way they are called in GitHub or Slack — through the control plane, with the same governance.
A custom internal endpoint registered on Guild gets the same scoped credentials, the same audit trail, and the same rate limiting as a pre-built integration. That's the point.
The SDK and CLI: Open Source, Not Open Season
Guild's build tools are open source. The SDK and CLI are free to use, inspect, and contribute to.
This isn't a marketing decision. It's a trust decision.
You should be able to read every line of the framework they run on. You should be able to build and test locally without a cloud dependency. And you shouldn't need to wonder what's happening between your code and the runtime.
The SDK
@guildai/agents-sdk — one package, TypeScript, typed inputs and outputs via Zod.
Three agent types for different jobs:
| Type | Control | Best For |
|---|---|---|
| llmAgent | Stochastic | Tasks expressible as a prompt + tools |
| AutomaticallyManagedStateAgent | Deterministic | Algorithmic workflows with predictable cost |
| SelfManagedStateAgent | Deterministic | Parallel tool calls, complex state |
The runtime is sandboxed by design. Agents can only import @guildai/agents-sdk and zod — no arbitrary npm packages, no Node.js built-in modules. This isn't a limitation. It's a security boundary. Your agents run in isolation, with only the tools they've been explicitly granted.
Here's a complete agent definition:
TypeScript
1import { llmAgent } from "@guildai/agents-sdk"2import { gitHubTools } from "@guildai-services/guildai~github"3import { jiraTools } from "@guildai-services/guildai~jira"4import { z } from "zod"5 6export default llmAgent({7 description: "Triages support tickets by severity and routes to the right team",8 inputSchema: z.object({9 ticketId: z.string(),10 content: z.string(),11 }),12 outputSchema: z.object({13 severity: z.enum(["P0", "P1", "P2", "P3"]),14 team: z.string(),15 summary: z.string(),16 }),17 tools: { ...gitHubTools, ...jiraTools },18 systemPrompt: `You are a support triage agent. Analyze the ticket,19 determine severity, identify the responsible team, and provide20 a summary with recommended next steps.`,21})
Typed I/O. Scoped tools. Declarative structure. The control plane handles everything else — versioning, credentials, observability, policies.
The CLI
Three commands from idea to production:
Shell
1$ guild agent init ticket-triage2✓ Created agent scaffold at ./ticket-triage3 4$ guild agent test --ephemeral5✓ Running in isolated environment...6✓ All checks passed7 8$ guild agent save --publish9✓ Published ticket-triage@1.0.0 to Guild
init scaffolds the agent. test runs it in an isolated environment. save --publish deploys it to the control plane with versioning, rollback, and governance. No Docker. No CI/CD pipeline. No YAML.
The build tools are free. The control plane is the product.
In one sentence: Guild's open-source SDK and CLI let developers build, test, and deploy agents from their terminal — the build tools are free and MIT-licensed, the control plane is the product.
What Launched
A vast playground. Guild ships with pre-built integrations for the services engineering teams use every day, custom REST endpoint registration for any internal API, and an open-source TypeScript SDK for agents you want to build from scratch. If your team can describe what they need, Guild can connect it.
Every integration — whether it's a pre-built GitHub connection or a custom intneral tool — runs through the same control plane. Same governance. Same audit trail. Same-scoped credentials.
Unlike closed-agent platforms that limit you to their prebuilt integrations, Guild lets teams connect to, REST API, or custom service — with governance built in. Unlike building your own integration layer, Guild handles credential management, audit logging, rate limiting, and connection health — so your team focuses on the agent, not the plumbing.
FAQs
Yes. The @guildai/agents-sdk package and the Guild CLI are both MIT licensed. You can inspect the source, build and test agents locally, and contribute to the project. The open-source tools are free. The control plane — governance, observability, and deployment infrastructure — is the product.
Guild ships with 10 pre-built service integrations: GitHub, Slack, Jira, Bitbucket, Azure DevOps, Confluence, Figma, Cypress, New Relic, and TestRail. Auth is configured once at the workspace level, and agents automatically receive scoped access.
When teams build custom integration layers, they're rebuilding credential management, audit logging, rate limiting, access control, and connection health monitoring from scratch. Guild provides all of this as platform infrastructure. Your team focuses on the agents and the tools — not the plumbing in between.
Guild is framework-agnostic and model-agnostic. The control plane works with agents built using any framework — Mastra, LangChain, CrewAI, AutoGen, or custom code. The SDK gives you the most integrated experience, but Guild doesn't lock you into a single way to build.
One control plane.
The complete agent lifecycle.
Get a working agent in under 10 minutes.
No credit card required.