Migrating from Amazon SQS to Naive

• Every queue lives behind IAM credentials (AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY or a role), an AWS account, and CloudWatch — disconnected from wherever the agent’s email, cards, secrets, and KYC live.
• The credential is coarse: a key with sqs:* (or even a scoped policy) is an account-level grant. There is no per-end-user queue — you build tenant isolation yourself with naming conventions and hand-written IAM policies.
• “Which customer’s agent enqueued that job, and what else can this agent touch?” is answered in IAM + CloudWatch for queues, and in unrelated systems for everything else. The queue has no shared accountability with the rest of the agent’s footprint.

• The tenant user that owns the queue is the same user that owns its email inboxes, its cards, its vault secrets, and its KYC.
• The agent never holds a cloud key. Naive owns the underlying cloud credentials and scopes every queue to your tenant (one queue per resource, namespaced + tagged, with a queue policy locked to your tenant’s task role) — the same model as Compute.
• Whether an agent may use the queue at all is decided by that user’s Account Kit, and every request is metered against the tenant’s plan — so a leaked agent key can’t quietly run up a bill on your raw AWS account.

​

Concept map

​

Before / after: the core path

import {
  SQSClient, CreateQueueCommand, SendMessageCommand,
  ReceiveMessageCommand, DeleteMessageCommand,
} from "@aws-sdk/client-sqs";

// Needs AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY (or a role) + a region
const sqs = new SQSClient({ region: "us-east-1" });

// Create the queue (account-level; you namespace + IAM-scope tenants yourself)
const { QueueUrl } = await sqs.send(new CreateQueueCommand({ QueueName: "jobs" }));

// Producer
await sqs.send(new SendMessageCommand({
  QueueUrl,
  MessageBody: JSON.stringify({ task: "resize", url: "https://..." }),
}));

// Consumer — long-poll, process, then delete each message
const { Messages = [] } = await sqs.send(new ReceiveMessageCommand({
  QueueUrl, MaxNumberOfMessages: 10, WaitTimeSeconds: 20,
}));
for (const m of Messages) {
  // ...process m.Body...
  await sqs.send(new DeleteMessageCommand({ QueueUrl, ReceiptHandle: m.ReceiptHandle }));
}
// → the queue is a slice of your AWS account behind an IAM key. No per-user
//   isolation, and no shared identity with the agent's email, cards, or vault.

import { Naive } from "@usenaive-sdk/server";

const naive = new Naive({ apiKey: process.env.NAIVE_API_KEY! });
const client = naive.forUser("acme"); // same id space as your own users

// Create the queue — scoped to this end-user, no cloud key in the agent
const q = await client.queue.create({ name: "jobs" });

// Producer
await client.queue.send(q.id, JSON.stringify({ task: "resize", url: "https://..." }));

// Consumer — long-poll, process, then ack each receipt handle
const { messages } = await client.queue.receive(q.id, { max: 10, wait: 20 });
for (const m of messages) {
  // ...process m.body...
  await client.queue.ack(q.id, m.receipt_handle);
}
// → the SAME `client` also owns this user's email, cards, vault, and KYC.

• No key, no region wrangling. SQS needs IAM credentials and a region; the queue runs on your AWS trust. Naive runs the queue on cloud credentials it owns — the agent holds no cloud key and never sees a QueueUrl.
• The queue is per-user, not per-account. SQS gives you one account; you hand-build tenant isolation with naming + IAM. On Naive naive.forUser(id).queue is the isolation boundary.
• ReceiptHandle → receipt_handle, Body → body. Field casing changes; the semantics (long-poll, visibility timeout, at-least-once, ack-to-delete) are the same SQS semantics.
• The id is your identity, not a separate account. In SQS the key scopes SQS in one AWS account. In Naive the same forUser(id) handle also owns the agent’s email, cards, vault, and KYC.

​

FIFO, delay, and dead-letter queues

// DLQ first, then read its ARN, then wire a RedrivePolicy on the main queue
const { QueueUrl: dlqUrl } = await sqs.send(new CreateQueueCommand({
  QueueName: "orders-dlq.fifo",
  Attributes: { FifoQueue: "true" },
}));
const { Attributes } = await sqs.send(new GetQueueAttributesCommand({
  QueueUrl: dlqUrl, AttributeNames: ["QueueArn"],
}));

const { QueueUrl } = await sqs.send(new CreateQueueCommand({
  QueueName: "orders.fifo",
  Attributes: {
    FifoQueue: "true",
    RedrivePolicy: JSON.stringify({
      deadLetterTargetArn: Attributes!.QueueArn,
      maxReceiveCount: 5,
    }),
  },
}));

// FIFO send needs a MessageGroupId (and optionally a dedup id), plus optional delay
await sqs.send(new SendMessageCommand({
  QueueUrl,
  MessageBody: JSON.stringify({ order: 42 }),
  MessageGroupId: "u_123",
  MessageDeduplicationId: "order-42",
  DelaySeconds: 10,
}));

// One call: FIFO queue with a dead-letter queue provisioned for you
const q = await client.queue.create({ name: "orders", type: "fifo", dlq: true });

// FIFO send takes the group id (and optional dedup id), plus optional delay
await client.queue.send(q.id, JSON.stringify({ order: 42 }), {
  group_id: "u_123",
  dedup_id: "order-42",
  delay_seconds: 10,
});

• DLQ is a flag, not a two-queue dance. SQS makes you create the DLQ, read its ARN, and attach a RedrivePolicy. Naive provisions the DLQ when you pass dlq: true and tears it down with the parent on destroy.
• maxReceiveCount is not exposed on Naive — the redrive threshold is managed. If you tune it in SQS, note that as a gap.

​

Minimal viable migration

npm install @usenaive-sdk/server

​

Consolidate further once you’re on Naive

// One IAM credential scopes SQS — and only SQS — across your whole account.
// Per-tenant isolation is a naming + IAM policy you maintain yourself.
const { QueueUrl } = await sqs.send(new CreateQueueCommand({
  QueueName: `tenant-${customer.id}-jobs`, // your convention
}));
await sqs.send(new SendMessageCommand({ QueueUrl, MessageBody: "..." }));

// The card, the vault secrets, the email inbox, and the KYC for this customer's
// agent live in entirely separate systems with their own tenancy.

// One tenant user per customer isolates *every* primitive.
const acme = await naive.users.create({
  external_id: customer.id,
  email: customer.email,
});

const client = naive.forUser(acme.id);

// The queue is scoped to this user — no naming convention, no IAM policy:
const q = await client.queue.create({ name: "jobs" });
await client.queue.send(q.id, "...");

// The SAME client owns this customer's email inbox, card, vault, and KYC —
// one identity, isolated end to end.
await client.email.createInbox({ local_part: "agent" });
await client.cards.create({ name: "Ops", spending_limit_cents: 25_000, provider: "managed_virtual" });

​

Gain #1 — one identity across primitives

• With SQS, the agent’s queues are a slice of one AWS account, and per-tenant isolation is a naming convention plus IAM policy you write and audit yourself. With Naive, naive.forUser(acme.id) is a single handle to queue and email and cards and vault and KYC.
• Each queue is namespaced + tagged and locked to that tenant’s task role automatically — sibling tenants can never read each other’s queues, secrets, cards, or logs. Tear the customer down from one place.

​

Gain #2 — execution-time governance

• Whether an agent may use the queue at all is policy on the identity — not an IAM policy you maintain in a second console. Toggle the queue primitive per user in the Account Kit, and every request is metered against the tenant’s plan quota.

// A starter tier: queue enabled, capped by the plan's quota; no card for this tier.
const starter = await naive.accountKits.create({
  name: "Starter",
  primitives_config: {
    queue: { enabled: true },
    cards: { enabled: false },
  },
});
await naive.accountKits.assignUser(starter.id, acme.id);

// The plan carries the per-primitive quota that meters queue usage at execution time.
await naive.plans.upsert({
  key: "starter",
  name: "Starter",
  accountKitId: starter.id,
  period: "month",
  quotas: { queue: 100_000 },
});
await naive.forUser(acme.id).billing.setSubscription({ planKey: "starter" });

• The agent’s code path stays the same for every tier — client.queue.send(...), client.queue.receive(...). What changes at execution time:
  • Disabled primitive → the call is refused. If the Account Kit doesn’t grant queue, the request never reaches AWS.
  • Quota exceeded → 429. Once usage crosses the plan’s queue quota for the period, the call is rejected with a rate_limited error — no surprise AWS bill from a runaway agent.
  • The agent holds no cloud key. Naive owns the AWS credentials; a leaked agent key can’t enumerate or drain queues on your raw AWS account.

​

Gain #3 — unified accountability

• Every queue create, send, receive, and purge for a customer lands in one per-user activity log — alongside their email, card, vault, and KYC events, not in a separate CloudWatch namespace:

const { events } = await naive.forUser(acme.id).logs.query({ limit: 50 });
// "what did this agent enqueue, for whom?" — queue, email, cards, vault, one timeline

• That is the question that is hard to answer when queues live in SQS/CloudWatch, secrets live in your own manager, cards live in Stripe, and email lives somewhere else. Under Naive it is a single query.

​

What does not map yet

​

Where to go next

• queue primitive — standard / FIFO, DLQ, send / receive / ack, worker pattern
• queue SDK sub-client — typed method signatures
• queue CLI — create / send / receive / ack / attributes
• Compute — pair a service worker that long-polls the queue for a cheap autoscaling consumer
• Customer billing — the plan + quota that meters queue usage at execution time
• Account Kits — the policy model that enables/disables the queue per user
• Tenant users — the identity that owns the queue, compute, email, cards, and vault

​

Related reading (blog)

• Why consolidate agent infra on one governed identity — migration thesis behind this guide
• Building AI Agents Into Your SaaS — tenant user anchor for every migration
• How To Build An Agentic Data Pipeline Platform — queue-backed pipeline tutorial