Building Inquir Compute: Serverless Functions for AI Agents, Background Jobs, and Long-Running Workflows

Aleksandr Kubarskii — Fri, 15 May 2026 14:07:22 +0000

Most serverless platforms are great when your function is small, stateless, and finishes quickly.

But modern AI applications often do not look like that.

They need to:

run background jobs
process files
call LLMs
execute multi-step pipelines
expose API endpoints
handle webhooks
run scheduled tasks
keep containers warm
preserve logs and traces
avoid Kubernetes complexity

That is the problem I am working on with Inquir Compute.

Inquir Compute is an AI-first Function-as-a-Service platform designed for developers who want to deploy functions, API endpoints, cron jobs, webhooks, and background workflows without managing Kubernetes, containers, ingress, scaling logic, or infrastructure boilerplate.

Why I started building it

I originally worked on Inquir as a search-as-a-service product.

The idea was simple: help developers build search engines over different data sources.

But while building ingestion pipelines, I noticed something interesting.

A lot of the hard parts were not just about search.

They were about compute.

For example:

fetch data from external APIs
normalize and enrich documents
split content into chunks
call AI models
index the result
retry failed steps
run jobs on a schedule
expose parts of the workflow through HTTP APIs

At some point, the ingestion pipeline itself became the most interesting part of the system.

That was the pivot.

Inquir Compute was born from the idea that AI applications need a simpler way to run server-side logic.

Not just short-lived functions.

But real workflows.

The problem with traditional serverless

AWS Lambda, Vercel Functions, Cloudflare Workers, and similar platforms are powerful.

But when you build AI-heavy systems, you quickly hit limitations.

Some common issues:

1. Timeouts

AI workflows are not always fast.

A function may need to:

process a large document
call multiple LLM APIs
wait for an external service
crawl a website
transform data
execute several dependent steps

Short execution limits become painful very quickly.

2. Cold starts

For many APIs, cold starts are acceptable.

For AI agents and interactive workflows, they are not always acceptable.

If a user is waiting for an agent to respond, container startup time matters.

3. Background jobs are awkward

A lot of platforms are optimized for request-response functions.

But real products need background work:

send emails
process uploads
generate reports
sync data
update embeddings
call webhooks
clean old records
run scheduled tasks

Developers often end up connecting several services together just to run a job reliably.

4. Kubernetes is too much for small teams

Kubernetes is powerful, but it is also a lot of operational overhead.

For many indie hackers, startups, and small engineering teams, the ideal experience is:

I write a function, deploy it, expose it as an API, schedule it, and see logs.

Not:

I configure deployments, services, ingress, secrets, volumes, autoscaling, observability, and routing manually.

What Inquir Compute does

Inquir Compute is a serverless compute platform focused on developer experience.

The core idea is simple:

Write backend logic as functions and run them as APIs, cron jobs, webhooks, background tasks, or pipeline steps.

A function can be used in different ways.

For example, the same function could be:

exposed as an HTTP endpoint
triggered by a cron schedule
called inside a pipeline
used as a webhook handler
executed manually from the dashboard
used by an AI agent

Example: a simple function

A function can be as simple as this:

export default async function handler(event) {
  const name = event.queryStringParameters?.name || "developer";

  return {
    statusCode: 200,
    body: {
      message: `Hello, ${name}!`,
    },
  };
}

Then it can be mapped to an API route like:

GET /hello

And called from the outside:

curl https://your-domain.com/api/gw/workspace/hello?name=Alex

The goal is to make deployment feel closer to writing application logic, not managing infrastructure.

API endpoints

Inquir Compute includes an API Gateway-like layer.

That means functions can be mapped to routes:

GET /users/:id
POST /webhooks/stripe
POST /agent/chat
GET /reports/:reportId

The function receives an event object similar to common serverless platforms:

export default async function handler(event) {
  const userId = event.pathParameters.id;

  return {
    statusCode: 200,
    body: {
      userId,
      message: "User profile loaded",
    },
  };
}

This makes it possible to build small APIs without setting up a traditional backend server.

Cron jobs

AI and data applications often need scheduled execution.

For example:

run a daily sync
update search indexes
refresh cached data
send scheduled reports
check external APIs
run cleanup jobs

With Inquir Compute, the goal is to make cron a first-class concept.

Example:

0 2 * * *

This could trigger a function every day at 2 AM.

export default async function handler() {
  console.log("Running nightly sync");

  // Fetch data
  // Transform it
  // Store it
  // Send report

  return {
    statusCode: 200,
    body: {
      ok: true,
    },
  };
}

Webhooks

Webhooks are another common use case.

You may want to receive events from:

Stripe
GitHub
Telegram
Slack
Notion
custom internal systems

Instead of running a full server just to receive webhook events, you can deploy a function:

export default async function handler(event) {
  const payload = JSON.parse(event.body);

  console.log("Webhook received:", payload);

  return {
    statusCode: 200,
    body: {
      received: true,
    },
  };
}

Then expose it as:

POST /webhooks/github

Pipelines

One of the most important concepts in Inquir Compute is the pipeline.

AI workflows are rarely a single function.

They are usually a chain of steps:

Fetch data
→ Clean data
→ Chunk content
→ Generate embeddings
→ Store result
→ Notify user

Or:

Receive user request
→ Call LLM
→ Search knowledge base
→ Call another tool
→ Generate response
→ Save trace

A pipeline can be sequential or parallel.

Some steps may depend on previous steps.

Some steps may need retries.

Some may have conditions.

The long-term goal is to make these workflows easy to build and observe.

Hot containers

A major design idea behind Inquir Compute is keeping containers warm.

Instead of always starting a new container for each invocation, Inquir Compute can keep function containers available for reuse.

This is especially useful for AI workloads where startup time can be expensive.

For example, a function may need to load:

an SDK
a model client
configuration
cached data
dependencies
initialization logic

Keeping containers warm can improve the developer and user experience.

Observability by default

Serverless is only useful if you can understand what happened.

For each function or pipeline run, you need visibility into:

logs
execution time
errors
input/output
failed steps
retries
traces

Inquir Compute is designed with built-in observability so developers do not need to wire everything manually from day one.

Why not just use Kubernetes?

You can absolutely build something like this on Kubernetes.

In fact, under the hood, many platforms eventually need container orchestration concepts.

But most developers do not want to start there.

For many projects, Kubernetes is too low-level.

You need to think about:

deployments
services
ingress
autoscaling
secrets
namespaces
persistent volumes
container lifecycle
monitoring
networking

Inquir Compute tries to hide most of that behind a simpler abstraction:

Function → Route → Job → Pipeline → Logs

The developer should focus on application logic.

Who is it for?

Inquir Compute is mainly for developers building:

AI agents
internal tools
SaaS backends
data pipelines
webhook-based systems
scheduled jobs
API endpoints
automation workflows
document processing systems
search and RAG pipelines

It is especially useful when you want serverless simplicity but need more flexibility for long-running or background workloads.

Example use case: AI content pipeline

Imagine you want to build an AI content pipeline.

The workflow could look like this:

1. Read topic from database
2. Generate article outline
3. Generate draft
4. Improve SEO
5. Generate social post
6. Save result
7. Send notification

Each step can be a separate function.

export default async function generateOutline(event) {
  const { topic } = event.input;

  // Call LLM here

  return {
    outline: [
      "Introduction",
      "Problem",
      "Solution",
      "Example",
      "Conclusion",
    ],
  };
}

Then another function can generate the article.

Another one can create a LinkedIn post.

Another one can publish or schedule the result.

This is the kind of workflow that does not always fit well into classic request-response serverless functions.

The bigger vision

I think AI applications need a new kind of backend platform.

Not just hosting.

Not just functions.

Not just containers.

But a compute layer designed around:

agents
tools
workflows
long-running tasks
scheduled jobs
API routes
observability
developer experience

That is what I am trying to build with Inquir Compute.

Current status

Inquir Compute is still evolving, but the core direction is clear:

deploy functions from the browser
expose functions as API endpoints
run background jobs
run cron jobs
build pipelines
keep containers warm
provide logs and traces
reduce infrastructure overhead

The goal is not to replace every cloud platform.

The goal is to make it much easier to build and run AI-first backend logic.

Final thoughts

Serverless made backend deployment much simpler.

But AI applications are changing what backend workloads look like.

They are longer-running.

They are more stateful.

They depend on external APIs.

They need background execution.

They need orchestration.

They need visibility.

And they should not require every developer to become a Kubernetes expert.

That is why I am building Inquir Compute.

If you are building AI agents, automation workflows, data pipelines, or serverless backends, I would love to hear what problems you are running into.

In case you like it, I will share more insights on technical solutions I came up to.

DEV Community: Aleksandr Kubarskii