{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidrgidxomnp3b7bm77ecwozgui5sb3spfg7inelyrvjugomvvhyxi",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mkwl23qucwu2"
  },
  "path": "/t/the-openai-api-unlocked-a-whole-new-layer-of-building-for-me/1380174#post_5",
  "publishedAt": "2026-05-03T06:02:04.000Z",
  "site": "https://community.openai.com",
  "textContent": "That is exactly the part I ended up spending the most time thinking about.\n\nFor me, it is not fully manual, but I also would not trust a plain vector search or an LLM on its own to decide everything.\n\nThe way I think about it is pretty simple: the current task decides what kind of context is needed first. Then the runtime builds a small working view from the durable project state, the current run state, recent events, saved summaries, and any relevant files or artifacts.\n\nRetrieval can help find candidates, and the model can help reason over them, but I still want the runtime to be in charge of what actually enters the prompt.\n\nSo the model is not carrying the memory. It is working inside a temporary view of the memory.\n\nAfter each step, anything important gets written back into durable state, so the next step can continue without replaying the whole history again.\n\nThat separation has been the biggest unlock for me: the model reasons, but the runtime owns the memory, state, limits, and continuation logic.",
  "title": "The OpenAI API unlocked a whole new layer of building for me"
}