AWS SQS
Connic polls the SQS queue, runs the linked agents on each message, and deletes it only when every run completes. Failed messages return after the visibility timeout and follow the configured DLQ policy, with no workers to run.
Overview
Give the connector a queue URL, a region, and scoped IAM credentials, and Connic long polls the queue. Each message body is parsed as JSON and dispatched to the linked agents with the queue metadata attached under _sqs: message ID, receipt handle, queue URL, receive count, and sent timestamp. The message is deleted only when every linked agent's run completes; if a run fails, the message stays on the queue and reappears after the visibility timeout.
That is the entire worker fleet. Polling cadence, batch size, and visibility timeout are connector settings rather than code, and retry behavior falls out of standard SQS semantics: failed messages retry, and repeat failures land in the dead-letter queue configured in AWS.
How it works
Create the queue and an IAM user
Use a standard or FIFO queue and grant the IAM user sqs:ReceiveMessage, sqs:DeleteMessage, sqs:ChangeMessageVisibility, and sqs:GetQueueAttributes on it. Outbound connectors need sqs:SendMessage and sqs:GetQueueAttributes on the target queue instead.
Create the connector
Add an AWS SQS connector from the agent's Connector Flow in Inbound mode, then enter the queue URL, region, and AWS credentials. Tune Max Messages (1 to 10 per poll), Wait Time (long polling up to 20 seconds), and Visibility Timeout (300 seconds by default).
Link agents, optionally publish results
Connic starts polling and dispatches each message to all linked agents. Add an outbound connector pointing at another queue and completed run results are sent there for downstream processing.
Production patterns
Patterns teams ship in production, with Connic running the queues, workers, and schedulers.
Order lands in queue
sqs://orders-queueAgent pulls customer history, confirms stock, picks a carrier, and emits a fulfillment job to the next queue while the checkout API stays within its 200ms budget.
Order lands in queue
sqs://orders-queueAgent pulls customer history, confirms stock, picks a carrier, and emits a fulfillment job to the next queue while the checkout API stays within its 200ms budget.
Document queued
sqs://documents-queueAgent reads each document, returns vendor, line items, amounts, and due date as JSON, and pushes the record onward. Even at 10k messages an hour, Connic runs the worker fleet.
Document queued
sqs://documents-queueAgent reads each document, returns vendor, line items, amounts, and due date as JSON, and pushes the record onward. Even at 10k messages an hour, Connic runs the worker fleet.
New customer queued
sqs://onboarding-queueAgent cross-references signup data, drafts a welcome email tuned to the user's role, and enqueues day-2 and day-7 follow-ups. Failed runs land in the configured DLQ for replay.
New customer queued
sqs://onboarding-queueAgent cross-references signup data, drafts a welcome email tuned to the user's role, and enqueues day-2 and day-7 follow-ups. Failed runs land in the configured DLQ for replay.
Transaction queued
sqs://payments-queueAgent matches each payment to an open invoice, posts the entry to the ledger, and routes anything ambiguous to a finance reviewer with the candidate matches attached.
Transaction queued
sqs://payments-queueAgent matches each payment to an open invoice, posts the entry to the ledger, and routes anything ambiguous to a finance reviewer with the candidate matches attached.
Message lifecycle and retries
Messages are fetched with long polling (20 seconds by default) to keep empty responses and API calls down. A message is deleted from the queue only after every linked agent's run completes; a failed run leaves it in place, so it becomes visible again after the visibility timeout and is retried. While runs are in flight, Connic extends the message's visibility automatically, so a long run does not cause premature redelivery. For messages that fail repeatedly, configure a dead-letter queue on the AWS side and they end up there for inspection and replay.
Each message becomes a normal agent run, with full traces, token and cost tracking, and the same guardrails and approval rules as any other trigger. When a message keeps bouncing, the run history shows the exact cause.
Result payloads and FIFO queues
Outbound connectors publish a JSON result for each completed run: run_id, agent_name, status, output, error, timestamps, and token_usage. For FIFO queues, set a Message Group ID to keep ordering within a group; the deduplication ID is set to the run ID, so a result is never enqueued twice. See the payload formats and IAM policies in the SQS docs.
Information
- Publisher
- By Connic
- Connectors
- Connectors
- Modes
- Inbound, Outbound
- Documentation
- AWS SQS docs
Frequently Asked Questions
Bring the event source, payload shape, result destination, and any private-network or approval requirements. We will map AWS SQS to the right Connic connector mode, deployment path, and observability setup.
Talk to Sales