AWS SQS
Connic polls your SQS queue, runs your agents on each message, and deletes it only when every run completes. Failures redeliver via the visibility timeout into your DLQ policy, and you don't run the workers.
Overview
Give the connector a queue URL, a region, and scoped IAM credentials, and Connic long polls the queue for you. Each message body is parsed as JSON and dispatched to your 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 SQS semantics you already know: failed messages retry, and repeat failures land in whatever dead-letter queue you configure 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 your 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.
What you can build
Patterns teams ship in production. No queues, workers, or schedulers to run.
Order lands in queue
sqs://orders-queueAgent pulls customer history, confirms stock, picks a carrier, and emits a fulfillment job to the next queue — keeping the checkout API on 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 — keeping the checkout API on its 200ms budget.
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 you exactly why.
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
- Category
- Connectors
- Modes
- Inbound, Outbound
- Documentation
- AWS SQS docs
Frequently Asked Questions
How do I process SQS messages with an AI agent?
What happens when an agent run fails?
Does the SQS connector support FIFO queues?
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