Use case · Inquir Compute

Production AI agents on Inquir functions and gateway routes

Each tool is a Lambda-compatible function in its own container: call it through the gateway with auth and workspace secrets, add layers for heavy SDKs, use warm pools for bursty calls, pipelines when work outlives the HTTP timeout.

Build a tool endpoint →Serverless for AI agents

Situation

What agents actually need

A chat completion is only the headline. Production agents also fetch private data, write to systems of record, escalate to humans, and enforce guardrails—and each of those steps needs clear failure and retry semantics.

When there is no real backend, side effects creep into prompt text or the user’s browser, where they are nearly impossible to audit or revoke cleanly.

Why workarounds fail

Fragile patterns

Running privileged tools on end-user devices breaks the moment data is regulated or the user is on a locked-down laptop.

Throwing every tool into one giant server turns every deploy into a high-risk change and makes log lines impossible to attribute to a specific capability.

How Inquir fits

Composable tools in Inquir

One function per tool keeps dependencies and deploy risk localized; execution history in the console matches each tool invocation—easier on-call than a shared monolith.

Handlers use the same Node, Python, or Go runtimes as the rest of the platform. Optional warm pools trim cold-start overhead when the model calls tools in a tight loop—measure under realistic load.

Capabilities

Building blocks

Auth-aware routes

Different tools, different credentials.

Async continuation

Offload long steps to pipelines when users cannot wait.

Structured logs

Correlate model decisions with tool outcomes.

Steps

How to build agent tools on Inquir Compute

Plan tools

Define JSON schemas for inputs and outputs.

Implement

Keep handlers deterministic where possible.

Observe

Alert on error rates per tool, not only per chat session.

Code example

Small tool handler

POST JSON arrives as event.body string; respond with { statusCode, body } for HTTP integrations.

tools/lookup.mjs

export async function handler(event) {
  const id = JSON.parse(event.body || '{}').id;
  const row = await db.findById(id);
  return { statusCode: 200, body: JSON.stringify({ row }) };
}

Fit

Good fit

When to use

Multi-step agents
Tool access to private data

When not to use

Stateless single-shot completions with no side effects

FAQ

Should agent tools be separate HTTP functions?

Yes for production: one function per tool (or tight group) keeps dependencies isolated, deploy risk small, and logs attributable—easier than a monolith that mixes user sessions and tool IO.

How do I store secrets for tool calls?

Use Inquir workspace secrets and environment injection so API keys never live in prompts or client bundles; rotate keys independently of model versions.

Streaming responses to the user?

End-user streaming is a gateway concern; many tool-calling stacks still use plain request/response JSON between the orchestrator and each tool because retries and idempotency stay simpler that way.