Add agents to your SaaS — without rewriting your service layer.

HyperGaaS is the agent stack for SaaS that's already shipped. One decorator on a service method you already have. The SDK derives the tool schema from your TypeScript types, scopes the call to the right tenant, checks permissions, writes the audit log, and pauses irreversible actions for approval — in the file your business logic already lives in.

class JobService {
  @agentAction({
    description: "Get a technician's schedule for a given date",
    reversibility: "idempotent",
    requiredPermissions: ["schedule:read"],
    audienceRoles: ["dispatcher", "owner", audience.self((ctx, p) => ctx.userId === p.techId)],
    costWeight: 1,
  })
  async getTechSchedule(ctx: AgentContext, params: { techId: string; date: Date }) {
    // ctx.tenantId is injected and validated. Permissions pre-checked.
    // Audit log written. Tool schema derived from these types — no parallel copy.
    return this.db.schedule.find({ tenantId: ctx.tenantId, ...params });
  }
}

npm install @hypergaas/core Star on GitHub

Every agent SDK was built for agents from scratch. You already have a product.

You have tenants. You have a permission system. You have a service layer with dozens of methods and an audit trail your customers — sometimes your regulators — expect. The problem isn't building an agent. It's running one inside the product you already shipped: on the same tenant scoping, the same RBAC, the same business logic your human users run on.

No agent SDK solves this. They assume you're starting from nothing. So for every method you want an agent to call, you write it three times: the real service method, a parallel JSON schema that drifts the moment you add a field, and a handler that hand-threads tenantId, copy-pastes the permission check, and bolts on audit logging. Miss the tenant ID once and you have a cross-tenant data leak — a P0 incident in any multi-tenant SaaS. Those wrappers become a second service layer that drifts from your real one, and the cost of the tenth agent feature never comes down.

OpenAI's Agents SDK is the loudest version of this gap. Four primitives, marketed as the default way to build agents — and every SaaS team that reaches for it walks straight into rebuilding tenant context, permission checks, audit logging, and reversibility gating by hand, because the SDK has no concept of any of them. Its provider-agnosticism is a claim retrofitted onto an OpenAI-first design. We don't say that as a take; we built the alternative and shipped it on npm as @hypergaas/core: two tenants in one process with structurally impossible cross-tenant leaks via the agent path, permission and reversibility gating enforced at runtime, paired PROPOSED/COMPLETED audit records — 49 passing tests, no any in the public surface. HyperGaaS ships the layer OpenAI makes you rebuild.

The others are closer to right, and we credit them where they are. LangGraph is production-grade for graph-based state machines — but it's general-purpose orchestration with a steep curve and no multi-tenant primitives. CrewAI is great for fast role-based prototyping, and teams routinely outgrow it at production scale. Mem0 and Zep solved real problems in agent memory and informed how we think about tenant-scoped memory. None of them are a SaaS integration layer. That gap is the whole reason HyperGaaS exists.

From a service method to a tenant-scoped, audited agent action in five minutes.

Install, decorate a method you already have, build a context, invoke. At the end you have a permission-checked, tenant-scoped call with an audit trail — and you wrote none of the plumbing.

npm install @hypergaas/core

// 1. Bind your roles to the registry once, at module scope.
import { defineRoles, audience, createActionRegistry, type AgentContext } from "@hypergaas/core";

const roles = defineRoles({
  owner: { displayName: "Owner", seniority: 4, canApproveIrreversibleUpTo: "high" },
  dispatcher: { displayName: "Dispatcher", seniority: 3, canApproveIrreversibleUpTo: "medium" },
  technician: { displayName: "Technician", seniority: 1 },
});

const { agentAction, invoke } = createActionRegistry(roles);

// 2. Decorate a service method you already have. No parallel schema, no handler.
class JobService {
  @agentAction({
    description: "Get a technician's schedule for a given date",
    reversibility: "idempotent",
    requiredPermissions: ["schedule:read"],
    // 'dispatcher' | 'owner' are checked against your role registry — a typo is a
    // compile error. audience.self(...) infers params from the method signature.
    audienceRoles: ["dispatcher", "owner", audience.self((ctx, p) => ctx.userId === p.techId)],
    costWeight: 1,
  })
  async getTechSchedule(ctx: AgentContext, params: { techId: string; date: Date }) {
    return this.db.schedule.find({ tenantId: ctx.tenantId, ...params });
  }
}

import { createAgentContext, isOk } from "@hypergaas/core";

// 3. Build one context per request. It is the only source of tenant identity —
//    set it once at your request layer and never thread tenantId by hand again.
const ctx = createAgentContext({
  tenantId: "acme-hvac",
  userId: "u_marcus",
  role: "dispatcher",
  permissions: ["schedule:read"],
  autonomyLevel: "medium",
});

// 4. Invoke. Permissions and tenant scope are enforced before the body runs;
//    the result is typed, not thrown.
const result = await invoke("JobService.getTechSchedule", ctx, {
  techId: "u_marcus",
  date: new Date("2026-05-25"),
});

if (isOk(result)) {
  console.log(result.value); // the schedule, scoped to tenant "acme-hvac"
}

// The default in-memory audit logger now holds a paired PROPOSED + COMPLETED
// record for this call — actionKey, tenantId, userId, role — without you writing
// a line of audit code. Swap InMemoryAuditLogger for a durable backend behind the
// same interface when you go to production.

What it isn't

HyperGaaS is not a workflow engine. It's the SaaS integration layer that makes your existing service layer agent-callable — with tenant scoping, permissions, reversibility classes, and audit logging built into the action model at declaration time.

It is not another general-purpose orchestration framework. If you need durable, long-running execution, run it on something built for that — Temporal, or whatever your team already trusts. HyperGaaS sits at the boundary where an agent meets your business logic: it turns the methods you already have into governed actions. Use it alongside your service layer and your workflow engine, not instead of either.

Read the code. Star the repo.

HyperGaaS is open source and TypeScript-first. The v0.1 public surface — the action registry, the typed role registry, and multi-tenant context — is on GitHub. Full documentation is on the way.

github.com/Hypergaas/hypergaasDocs — coming soon