DEV Community

flisk
flisk

Posted on

Running a Python or LangGraph Agent as a Flisk Worker, With Dependencies Declared

#ai #agents #flisk #python

Not every agent answers HTTP requests. Some work through a queue: they pick up a task, call a model, write a result, and wait for the next one. Flisk's worker resource type fits that shape. The docs describe a Python or LangGraph agent running as a worker, with Postgres and NATS declared as dependencies.

Scaffold the worker 

flisk resource research-agent --type worker --stack shop --yes
Enter fullscreen mode Exit fullscreen mode

Then declare what the worker needs in its service.json:

{
  "name": "research-agent",
  "appType": "worker",
  "stack": "shop",
  "dependsOn": ["postgres", "nats"],
  "env": {
    "DATABASE_URL": "@ref(postgres.DATABASE_URL)",
    "NATS_URL": "@ref(nats.NATS_URL)"
  }
}
Enter fullscreen mode Exit fullscreen mode

The dependsOn list sets the start order. The @ref(...) values pull connection strings from the services you named, so the worker does not hard-code them.

What the order guarantees

The docs say the worker boots only after Postgres and NATS pass their readiness gates. That matters for an agent. A worker that starts before its queue is up will fail on its first poll, and the failure looks like a bug in the agent rather than a startup race.

They also say the worker reconnects smoothly during a hot reload. Check that behaviour in your own setup, since reconnect logic lives in your code as much as in the stack.

What the worker should do

A worker agent should be idempotent. A task that runs twice should not send two emails or write two rows. Use the task ID as a key, and write the result before you mark the task done.

Log each task with its ID. When a task fails, you need to find the run that failed, not scroll through a stream.

Set a retry limit. A worker that retries a failing model call forever burns cost. After the limit, move the task to a failed state with the error attached.

Check the start order

Before you rely on it, run the dry run and read the plan:

flisk up shop --dry-run
Enter fullscreen mode Exit fullscreen mode

The plan should show Postgres and NATS before the worker. If it does not, the dependsOn list is wrong, and the worker will start too early.

What a worker is not

A worker is not a session server. There is no x-session-id routing, because a queue does not carry conversations. If your agent needs a conversation that survives a restart, the agent resource is the closer fit, as the first article in this series covers.

Summary

A background agent fits the worker resource. Declare its database and broker in dependsOn, pass their URLs with @ref, make the task handling idempotent, cap the retries, and check the start order in the dry run before you start.

Top comments (0)