how do you classify production AI agents in your infrastructure web app, batch job, or something new?

ive been doing infrastructure work for around 7 years, last 18 months specifically running AI agent workloads in production. 5 agents, ~50M tokens/month combined, mostly on AWS with bullmq for queues and postgres for state.

the thing thats genuinely confusing me: AI agents dont quite fit any of the boxes i was trained in.

theyre not stateless web apps agents carry conversation state, intermediate tool outputs, retry context. running them like ECS web services means losing conversational state on container restart.

theyre not batch jobs they need to respond to webhooks in seconds, not minutes. cant treat them like cron jobs.

theyre not microservices too much state passing between services turns the orchestration layer into a distributed transaction nightmare.

what ive ended up with feels weird. agents run as long lived workers polling a queue, state lives in postgres + redis, every external tool call gets idempotency keyed at the edge, observability is split across cloudwatch (infra metrics) and s3/athena (llm input/output traces because cloudwatch costs got out of hand).

things i still dont have good answers for:

• where should i set timeouts on agent runs? web app timeouts (30s) kill complex tasks. batch job timeouts (hours) hide infinite loops. middle ground feels arbitrary
• whats the right SLO model for a non deterministic system? cant promise 99.9% correctness when the underlying model is probabilistic
• how are people doing blue/green or canary deploys when agent behavior depends on prompt versions interacting with model versions
• where do you draw the line between agent decides vs ops team approves ive been adding human in loop for irreversible actions but the policy feels ad-hoc

curious how others are handling this in production. are you treating agents as a new infrastructure pattern or forcing them into one of the existing boxes? specifically interested in how teams further along have structured their on call response for agent failures, since the failure modes look nothing like web app failures.