Short answer: not directly. In Prefect 3.x you can’t index a single PrefectFuture (e.g.,

future[0]

) to create a “sub‑future” for that element. A

PrefectFuture

represents one task’s entire result, and it doesn’t implement

__getitem__

. Practical patterns that work: - Return what you need from the upstream task - If you can, have the upstream task return a dict with the keys you want so you don’t need to split later. - Use tiny “extractor” tasks to split the result - Create small tasks that pick out the i-th element or a dict key. Prefect will wait on the upstream future automatically when those extractor tasks run, but you don’t have to call

.result()

yourself. - You can then build a dict of futures and pass it downstream; Prefect will resolve nested futures before the consuming task executes. Example:

from prefect import flow, task

@task
def produce():
    # returns multiple elements
    return ["alpha", "beta", "gamma"]

@task
def get_item(seq, i):
    return seq[i]

@task
def get_key(d, key):
    return d[key]

@task
def consume(parts):
    # Here `parts` arrives with concrete values, not futures
    return f"{parts['first']} + {parts['second']}"

@flow
def my_flow():
    res = produce()                   # PrefectFuture
    first = get_item(res, 0)          # PrefectFuture (extracted)
    second = get_item(res, 1)         # PrefectFuture (extracted)

    parts = {"first": first, "second": second}  # dict of futures
    out = consume(parts)              # Prefect resolves nested futures automatically
    return out

if __name__ == "__main__":
    my_flow()

- If your upstream work is naturally “per-item”, map earlier - When you use

.map(...)

, you get a

PrefectFutureList

(a list of futures). You can index that list to get an individual PrefectFuture per item (because the list contains futures), which may fit your “split across keys” goal more naturally. References: - Task runners and how Prefect resolves futures passed to tasks - Running work concurrently (mapping, parallelism) - Prefect futures source If you share a quick snippet of your flow and what you want the final dict to look like, I can suggest the cleanest refactor (return a dict upstream vs. extractor tasks vs. mapping).