honeypoardHow Honeypoard works.
Honeypoard connects the services you already run, helps your team define what they mean together, and publishes approved capabilities for people and agents to use.
A practical look at the product, its review process, and where your data runs.
Connect once. Define with care. Use where work happens.
See · Ask · ActStart with the systems you have.
Import a REST or OpenAPI specification, a GraphQL schema, or an MCP catalog. Connect internal services and optional SaaS connectors. Honeypoard maps the available entities and operations into a workspace model, while keeping each connection distinct.
Sources stay recognizable.
Every source keeps its connection identity, operation details, and origin. Two connections of the same service are treated as separate connections.
Capabilities have a purpose.
Rather than exposing every endpoint as a tool, a capability can combine approved lookups, relationships, and output rules around a useful task.
What the product remembers: approved source metadata, relationships, capability definitions, governance rules, revisions, and publication state. Business records and execution results belong to the data plane.
Suggestions become useful when you can inspect them.
Honeypoard can suggest that two services share a business entity and propose a capability built on that link. The proposal shows its evidence and unresolved questions. Your team confirms the meaning, join keys, tenant scope, and permitted operations before publication.
Order → support ticket
● Approved relationship · revision 08
A matching field name alone does not prove a relationship. Ambiguous links stay out of published capabilities until resolved.
capability: order_context sources: - orders - support relationship: order_to_ticket output: approved_fields governance: audience: support_team action: read approval_required: false
Capability and governance definitions are versioned separately. The YAML is a readable representation of the reviewed definitions, not a place to hide executable code or credentials.
Publish a capability. Set who can use it.
Honeypoard validates the selected capability and policy revisions together, then publishes a pinned contract. A source change creates a proposed revision and impact to review; it does not silently change a live tool.
Views for people
Use the capability in private, shared, or embedded workspace views, with the relevant source context and freshness visible.
Answers with sources
Ask a question across the operations and fields you are allowed to use. The answer can point back to the connected source context.
Tools for assistants and agents
Expose approved capabilities through workspace MCP access for coding harnesses, or governed A2A access for your custom agents. Actions follow the same workspace permissions and approval rules.
Permission is checked when work happens.
Access rules apply to tool discovery, invocation, underlying operations, and returned fields. Consequential actions can require a person to approve the exact action before it runs. A model suggestion cannot grant itself permission.
Clear boundaries for your data.
Honeypoard Cloud manages workspaces, approved definitions, and publication. A separate data plane runs connectors and capabilities, holds credentials, and handles business data. The data plane is managed by Honeypoard by default; customer hosting is an Enterprise option.
Workspace metadata, reviewed definitions, revisions, publication state.
Connectors, secrets, live execution, business records, optional result storage.
A customer hosted data plane keeps execution and business results in the customer environment by default. Authorized browsers and chosen MCP or A2A clients can still receive the results they are permitted to request.
Explore deployment options ↗Answers before you build.
Does an AI model decide what is published?
No. Models can help propose mappings, relationships, and descriptions. Your team reviews the proposal, and deterministic validation checks the approved definitions before publication. A published execution plan does not ask a model to reinterpret its joins or permissions.
What happens when a connected service changes?
Honeypoard records a proposed revision and shows which relationships or capabilities may be affected. A published contract is pinned to its approved definition. If a source can no longer support safe execution, a dependent capability becomes unavailable until it is resolved.
How do connected APIs become reliable tools?
Honeypoard reads your service schemas, then suggests relationships and capabilities in a reviewable UI. Your team can inspect the evidence and relationship history, then approve the inputs and permissions. The resulting capability YAML can optionally be kept in source control. Publication pins the approved definition so the tool runs with deterministic joins and rules.
See the relationship review and capability YAML example in the product guide ↗
Where does our business data go?
Your business data stays in the connected systems unless you approve a capability that syncs or caches some of it. The data plane handles those reads and any approved copies. Honeypoard manages the data plane by default, while Enterprise customers can run it in their own environment. Honeypoard Cloud stores workspace settings and approved definitions, not your business records.
Can we host the data plane ourselves?
Yes. Enterprise customers can run the data plane in their own environment, so connections, credentials, processing, and any approved caches stay there. Honeypoard Cloud still manages workspace configuration and publication.
How do MCP and A2A differ here?
MCP lets an authorized coding harness or assistant use the approved tools in a workspace. A2A lets an agent your company builds connect to that workspace as an agent. Both use the published capabilities and applicable governance rules.
Can an assistant make changes to our systems?
Only through operations you explicitly publish for that audience. Permissions, input constraints, field restrictions, limits, and any required human approval are checked at execution. A read capability does not become a write capability because an assistant asks it to.