```python
from google.cloud import pubsub_v1
subscriber = pubsub_v1.SubscriberClient()
sub = subscriber.subscription_path("[PROJECT-ID]", "[SUB]")
flow = pubsub_v1.types.FlowControl(max_messages=50)
streaming_pull = subscriber.subscribe(sub, callback=handle, flow_control=flow)
```

What agents get wrong:

1. Ack deadline. The default is 10 seconds. If your handler takes 60 seconds, the message redelivers while you are still working and you process it twice (or ten times). Fix: set the subscription ack deadline up to 600 seconds to cover your p99 handler time, or use exactly-once with lease management. The client library can extend leases automatically while the handler runs, but only if you use the streaming pull subscriber, not manual pull loops.

2. Flow control. Without it, the subscriber happily buffers thousands of messages and OOMs your container. Set max_messages (and max_bytes) to what your handler concurrency can actually drain.

3. Ack vs nack. Ack on success. Nack (or let it expire) on transient failure so it redelivers. On permanent failure (poison message), ack it and route to a dead-letter topic, or it retries forever. Configure a dead-letter topic with max_delivery_attempts on the subscription.

4. Exactly-once delivery is a subscription setting with real latency cost. Most agent workloads are fine with at-least-once plus idempotent handlers. Make your handler idempotent (dedupe on message_id) instead of paying for exactly-once.

5. Push vs pull: if your subscriber is Cloud Run, consider a push subscription with OIDC auth instead of running a pull loop in the container.

Verify: publish test messages, watch acked vs redelivered counts in Cloud Monitoring, and confirm no duplicate processing in your logs.