I’ve been experimenting with LLM agents for a while and often felt that for simple workflows (chat, tool calls, small loops), existing frameworks add a lot of abstraction and boilerplate.

So I built a small Python library called PicoFlow. The goal is simple:

express agent workflows using normal async Python, not framework-specific graphs or chains.

Minimal chat agent

Each step is just an async function, and workflows are composed with >>:

  from picoflow import flow, llm, create_agent

  LLM_URL =
  “llm+openai://api.openai.com/v1/chat/completions?model=gpt-4.1-mini&api_key_env=OPENAI_API_KEY”

  @flow
  async def input_step(ctx):
      return ctx.with_input(input(“You:”))

  agent = create_agent(
      input_step >>
      llm(“Answer the user: {input}”, llm_adapter=LLM_URL)
  )

  agent.run()

Control flow is just Python

Loops and branching are written with normal Python logic, not DSL nodes:

  def repeat(step):
      async def run(ctx):
          while not ctx.done:
              ctx = await step.acall(ctx)
              return ctx
          return Flow(run)

Switching model providers = change the URL

Another design choice: model backends are configured via a single LLM URL.

OpenAI:

  LLM_URL =
  “llm+openai://api.openai.com/v1/chat/completions?model=gpt-4.1-mini&api_key_env=OPENAI_API_KEY”

  LLM_URL =
  “llm+openai://api.siliconflow.cn/v1/chat/completions?model=Qwen/Qwen2.5-7B-Instruct&api_key_env=SILICONFLOW_API_KEY”

When this is useful (and when it’s not)

PicoFlow is probably useful if you:

- want to prototype agents quickly - prefer explicit control flow - don’t want to learn a large framework abstraction

It’s probably not ideal if you:

- rely heavily on prebuilt components and integrations - want a batteries-included orchestration platform

Repo:

https://github.com/the-picoflow/picoflow

This is still early and opinionated. I’d really appreciate feedback on whether this style of “workflow as Python” is useful to others, or if people are solving this in better ways already.

Thanks!