Hey HN,
We're John and Nadeesha. We created Inferable. [1]
After years of working in operationally-intensive startups, we got tired of watching our internal tools gather dust and break. We've all been there - you build a tool, it works great for a while, then the API changes and suddenly you're back to square one. Sure, Retool and similar tools help, but someone still has to maintain them, and the backlog of "quick fixes" and the mountain of glue code keeps keeps growing.
We started Inferable to see whether LLMs can help here.
Inferable helps developers create conversational AI agents that act as the orchestration layer between existing internal APIs and human intent. Instead of building custom scripts or internal tools, developers can quickly set up these agents as conversational experiences [2].
We natively integrate with Slack and email (more coming), while also supporting Zapier and HTTP APIs for more advanced workflows.
Our SDKs can wrap existing functions, or existing APIs (REST, GraphQL). We use long polling for message delivery, which means these instances don’t have to open ports / configure network ingress.
A Re-Act agent dynamically searches through these tools based on user context, schedules jobs as tool calls, and iterates based on the result.
We prioritize using existing codebases as deterministic guardrails. For additional verifications, we provide primitives to easily implement human-in-the-loop processes, custom authn, and authz, all backed with your existing codebases.
Our customers use Inferable to:
- Interact conversationally with internal APIs and databases (with restricted connections)
- Programmatically process Datadog alerts - automatically tagging them and routing them with enriched context
- Programatically or conversationally enrich Zendesk support tickets by automatically adding context from multiple internal systems
To achieve this functionality, we've developed:
- A built-in Re-Act (reasoning + action) agent
- A distributed job queue for managing long-running tasks
- End to end chat state, and message serialisation for tool calls
- Service discovery and function registry for tools
- Context-aware dynamic tool search
- Native SDKs for Node.js, Golang, C#, and other languages
We’re open-source (MIT) and fully self-hostable within existing infrastructure. Happy to receive any feedback or answer questions.
---
[1] https://github.com/inferablehq/inferable
[2] Acknowledging that calling an LLM every time is costlier than using a script, we’re solving the problem of repeating these flows without LLM intervention in our next iteration.
Would there be a means of limiting which services and functions each query can call manually to impose more specified guardrails? and how is the “human in the loop” thing enforced?