[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-foundry-ship-agents-without-rewrites-en":3,"article-related-foundry-ship-agents-without-rewrites-en":30,"series-tools-60938346-4517-4a62-a8c0-ca6db24ed5d6":73},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"60938346-4517-4a62-a8c0-ca6db24ed5d6","foundry-ship-agents-without-rewrites-en","Foundry lets you ship agents without rewrites","\u003Cp data-speakable=\"summary\">Foundry keeps your agent stack portable from prototype to production.\u003C\u002Fp>\u003Cp>I've been building agents the way most of us did in 2024 and 2025: get something working fast, wire in a model, slap a tool or two on it, and call it a prototype. That part is fine. Honestly, that part is easy now. What kept bothering me was everything after the demo. The agent would behave one way in a notebook, another way in a service, and a third way once real users started poking it through a product flow. Tool auth turned into a pile of one-off glue. Memory was either fake, leaky, or bolted on too late. Observability stopped at the model call, which is a fancy way of saying I had no idea why the thing made a stupid decision at 2 a.m. When I read Microsoft's Build 2026 post on \u003Ca href=\"https:\u002F\u002Fdevblogs.microsoft.com\u002Ffoundry\u002Fagent-service-build2026\u002F\">Microsoft Foundry\u003C\u002Fa>, the thing that clicked was not \"more AI features.\" It was the admission that agents are now at the same annoying stage microservices hit years ago: the prototype is easy, the operating model is the work.\u003C\u002Fp>\u003Cp>That post is by Tina Schuchman on the \u003Ca href=\"\u002Ftag\u002Fmicrosoft\">Microsoft\u003C\u002Fa> Foundry Blog, published June 2, 2026. The framing is blunt: build in \u003Ca href=\"\u002Ftag\u002Fgithub\">GitHub\u003C\u002Fa>, run in Foundry, and reach users where they already are. I don't have bookmark counts or star numbers to wave around here, and I don't need them. The useful part is the architecture story. Microsoft is saying the agent harness should be a flex point, not a trap, and that is the part worth unpacking.\u003C\u002Fp>\u003Ch2>Stop treating the framework choice like a marriage\u003C\u002Fh2>\u003Cblockquote>“Microsoft Foundry treats the agent harness as a flex point, not a lock-in: investments in LangGraph, GitHub Copilot SDK, or Claude Agent SDK carry forward. If you're starting fresh, Microsoft Agent Framework is our opinionated, open-source agent framework, stable across Python and .NET.”\u003C\u002Fblockquote>\u003Cp>What this actually means is simple: Microsoft is trying to make the framework layer disposable enough that you can change your mind later without rewriting the whole stack. I like that, because I've lived through the opposite. I once backed myself into a corner with a slick orchestration library that looked great in local tests and became a tax the moment I needed to move the workflow into production. Every new workflow meant learning the framework's opinionated way of doing things, and every integration meant another adapter. That is how you end up defending the framework instead of shipping the product.\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784120662308-flld.png\" alt=\"Foundry lets you ship agents without rewrites\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>Foundry's pitch is that the framework is not the center of gravity. The center is the agent runtime, the tools, the memory, and the operational loop. If you start with \u003Ca href=\"https:\u002F\u002Flangchain-ai.github.io\u002Flanggraph\u002F\">LangGraph\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fagents\">GitHub Copilot SDK \u002F Microsoft Agent Framework\u003C\u002Fa>, or the \u003Ca href=\"https:\u002F\u002Fdocs.anthropic.com\u002Fen\u002Fdocs\u002Fagents-and-tools\u002Fclaude-agent-sdk\">Claude Agent SDK\u003C\u002Fa>, Microsoft says those investments still matter. If you're starting fresh, use \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fagent-framework\">Microsoft Agent Framework\u003C\u002Fa>, which is open source and split across Python and .NET. That matters to me because I do not want a platform that forces me to bet my whole app on its favorite abstraction on day one.\u003C\u002Fp>\u003Cp>How to apply it: separate your business logic from your orchestration choice. Your agent should expose a narrow interface for task execution, tool use, and state updates. Keep prompts, policies, and tool contracts versioned outside the framework. If you later move from one harness to another, the agent's job logic should come with you. The framework should be a transport layer for behavior, not the place where behavior lives.\u003C\u002Fp>\u003Cul>\u003Cli>Keep tool definitions in a shared schema, not buried in framework callbacks.\u003C\u002Fli>\u003Cli>Store prompts, policies, and routing rules in versioned files.\u003C\u002Fli>\u003Cli>Design for migration from the start, even if you never migrate.\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Build in the editor, not in a side quest\u003C\u002Fh2>\u003Cblockquote>“Foundry Toolkit for VS Code (GA) is the purpose-built developer experience without ever leaving the editor.”\u003C\u002Fblockquote>\u003Cp>What this actually means is Microsoft is trying to collapse the annoying gap between coding the agent and understanding what it did. That's a good move. I have no patience for workflows where I need one tool to author the agent, another to run it, another to inspect traces, and a fourth to deploy it. By the time I context-switch that much, I've forgotten what I was trying to debug.\u003C\u002Fp>\u003Cp>The \u003Ca href=\"https:\u002F\u002Fmarketplace.visualstudio.com\u002Fitems?itemName=ms-foundry.vscode-foundry\">Foundry Toolkit for VS Code\u003C\u002Fa> is the sort of thing I wish more platform teams would ship earlier. According to the post, you can create agents from templates or with \u003Ca href=\"\u002Ftag\u002Fgithub-copilot\">GitHub Copilot\u003C\u002Fa>, test and debug runs locally with full trace visualization, inspect behavior step by step, connect to Toolboxes, and deploy to Foundry Agent Service directly from VS Code. That's not a novelty feature. That's how you keep the feedback loop tight enough to matter.\u003C\u002Fp>\u003Cp>I ran into this exact problem on a small internal agent that triaged support tickets. The code was fine. The issue was that every change required a deploy just to see whether the tool chain still behaved. So I stopped iterating. That's the real cost: not compute, not tokens, but developer hesitation. If the editor can show traces and local runs before I push anything, I can keep moving.\u003C\u002Fp>\u003Cp>How to apply it: make local trace inspection part of your default workflow. If your \u003Ca href=\"\u002Fnews\u002Fgoogles-gemini-enterprise-agent-platform-cloud-service-en\">agent platform\u003C\u002Fa> does not let you see tool calls, memory reads, and branch decisions before deployment, you're debugging blind. Keep a local dev harness that mirrors production inputs. Then add a single command or button for deploying the same artifact to the managed runtime.\u003C\u002Fp>\u003Cul>\u003Cli>Use templates to standardize the first version of each agent.\u003C\u002Fli>\u003Cli>Capture traces in local runs, not just production.\u003C\u002Fli>\u003Cli>Make deployment a repeatable action from the same environment you code in.\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Tooling is where agents usually fall apart\u003C\u002Fh2>\u003Cblockquote>“Tools are how agents do things — calling APIs, searching documents, executing code, talking to other agents.”\u003C\u002Fblockquote>\u003Cp>That line is the entire problem statement. Most agents do not fail because the model cannot reason. They fail because every tool is a tiny integration project with its own auth, protocol, retries, and lifecycle. I have watched teams spend more time making three tools look the same than actually making the agent useful. It is exhausting, and it scales badly.\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784120663148-3coq.png\" alt=\"Foundry lets you ship agents without rewrites\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>Microsoft's answer here is \u003Ca href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Ffoundry\u002Ftoolboxes\u002Foverview\">Toolboxes in Foundry\u003C\u002Fa>, which the post describes as a single managed endpoint for every tool type. Configure tools once, point any MCP client at one URL, and let Foundry handle auth, lifecycle, and governance. That is the kind of sentence that sounds boring until you try to maintain twelve different connectors. Then it sounds like relief.\u003C\u002Fp>\u003Cp>The other piece I care about is \u003Ca href=\"\u002Ftag\u002Fskills\">skills\u003C\u002Fa>. The post says skills are first-class, versioned in a project-scoped catalog, and discoverable as MCP resources by any agent in the project. That is better than the usual pile of anonymous functions because it gives the agent a named, governed capability set instead of a junk drawer. The post also mentions tool search, which is exactly what I want once the tool list gets too long for a model to reason over cleanly.\u003C\u002Fp>\u003Cp>How to apply it: treat tools like product APIs. Give them stable names, version them, and document when to use each one. Do not expose every internal endpoint directly to the model. Create a curated tool catalog, then add a search or ranking layer so the agent sees only the relevant options. If you have multiple tool providers, normalize them behind one access point before the model ever sees them.\u003C\u002Fp>\u003Cp>I've had better results when I stop asking “what tools can the model use?” and start asking “what is the smallest useful tool surface for this job?” That question saves a lot of pain later.\u003C\u002Fp>\u003Cul>\u003Cli>Wrap raw APIs in a governed tool layer.\u003C\u002Fli>\u003Cli>Version skills like code, not like random config.\u003C\u002Fli>\u003Cli>Use tool search once the catalog grows past a handful of actions.\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Memory is not a feature add-on, it's the job\u003C\u002Fh2>\u003Cblockquote>“Memory makes those actions informed and better over time.”\u003C\u002Fblockquote>\u003Cp>That line is understated, which I appreciate. Too many agent demos treat memory like a novelty, usually by saving a paragraph of chat history and calling it intelligence. That is not memory. That is a transcript with optimism.\u003C\u002Fp>\u003Cp>The post breaks memory into three useful buckets inside Foundry Agent Service: procedural memory, user memory, and session memory. Procedural memory is the part I think most teams ignore. It lets the agent learn how to do the work across runs. Microsoft says early Tau-bench results show \u003Cstrong>+7–14% absolute success-rate gains\u003C\u002Fstrong> at near-baseline cost. I am not going to overread that number, but it does tell me procedural memory is not just a fancy cache.\u003C\u002Fp>\u003Cp>User memory is the obvious one: preferences and facts that should persist across sessions. Session memory is the short-term thread context that keeps a conversation coherent. Put together, these three layers stop the agent from acting like it has amnesia every time a request restarts.\u003C\u002Fp>\u003Cp>I ran into this with a PR-review agent. Without procedural memory, I had to remind it every single time to check tests before style, dependencies before approvals, and API changes before summary. Once the workflow got encoded as procedure, the agent stopped needing the lecture. That's the kind of memory that actually changes output quality.\u003C\u002Fp>\u003Cp>How to apply it: split memory by lifespan and purpose. Keep transient conversation context separate from user preference data. Then add a procedural layer for repeatable workflows, especially anything with ordered checks or compliance steps. Do not dump everything into one blob and hope retrieval sorts it out. It won't.\u003C\u002Fp>\u003Cp>If your agent is meant to do repeated work, memory should encode method, not just facts. That is the difference between a chatty assistant and something you can trust to follow a process.\u003C\u002Fp>\u003Ch2>Production needs an isolated runtime, not a hopeful script\u003C\u002Fh2>\u003Cblockquote>“Every session runs in its own sandbox, isolating every agent execution with dedicated compute, memory and filesystem.”\u003C\u002Fblockquote>\u003Cp>What this actually means is Microsoft is taking the unglamorous production problem seriously. Once an agent can execute code, touch files, call APIs, and hold state, you need isolation. You need predictable runtime behavior. You need a place where one bad session does not poison another. A notebook is not that place. A cron job is not that place. A production agent runtime is.\u003C\u002Fp>\u003Cp>\u003Ca href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Ffoundry\u002Fagent-service\u002Foverview\">Foundry Agent Service\u003C\u002Fa> is presented as the managed runtime for production agents, and the post says it is framework-agnostic. That matters because it means the runtime is not trying to own your orchestration choice. It is trying to own the boring but necessary parts: sandboxing, state, and scale. The post also says it supports the \u003Ca href=\"https:\u002F\u002Fplatform.openai.com\u002Fdocs\u002Fguides\u002Fresponses\">Responses API\u003C\u002Fa> for stateful interactions and an Invocations protocol for schema-free pass-through scenarios.\u003C\u002Fp>\u003Cp>That flexibility is useful if you need to deploy agents built with different stacks. The post specifically mentions Microsoft Agent Framework, GitHub \u003Ca href=\"\u002Ftag\u002Fcopilot\">Copilot\u003C\u002Fa> SDK, LangGraph, and other SDKs. I like this because I have seen too many platforms demand a rewrite before they will host your thing. That is not platform strategy; that is a tax.\u003C\u002Fp>\u003Cp>How to apply it: build your agent so the execution environment can be swapped. Keep filesystem assumptions explicit. Keep state serialized in a known format. Make retries idempotent where possible. And if your agent can run long-lived tasks, design for durable checkpoints rather than a single uninterrupted process. The runtime should recover work, not just host it.\u003C\u002Fp>\u003Cp>Also, stop assuming every agent is a single-turn chat. The post calls out long-running autonomous agents and routines. That is the real shape of production work: monitor, wait, resume, act, report. If your runtime cannot do that, it is missing the point.\u003C\u002Fp>\u003Ch2>Distribution matters more than another demo\u003C\u002Fh2>\u003Cblockquote>“Publishing to Microsoft Teams and Microsoft 365 Copilot.”\u003C\u002Fblockquote>\u003Cp>What this actually means is Microsoft wants the agent to show up where people already work, instead of asking users to visit a separate app and learn a new habit. I have a lot of sympathy for that. Internal tools die quietly when they require too much behavior change. If the agent is useful but awkward to access, it becomes a demo artifact, not a product.\u003C\u002Fp>\u003Cp>The Build post says hosted agents can be published into \u003Ca href=\"https:\u002F\u002Fwww.microsoft.com\u002Fmicrosoft-teams\">Microsoft Teams\u003C\u002Fa> and \u003Ca href=\"https:\u002F\u002Fwww.microsoft.com\u002Fmicrosoft-365\u002Fcopilot\">Microsoft 365 Copilot\u003C\u002Fa>. That is not just distribution. It is adoption strategy. It means the agent can live in the collaboration surface where requests, docs, meetings, and decisions already happen. That lowers the activation energy for users and makes the agent more likely to survive contact with real work.\u003C\u002Fp>\u003Cp>There's a second-order effect here too. When the agent sits inside an existing work surface, you can observe usage in context. You do not have to guess whether people remember a separate URL. They either use the thing where they already are, or they do not. That is a cleaner signal.\u003C\u002Fp>\u003Cp>How to apply it: choose the delivery surface before you obsess over the agent prompt. If your users live in chat, docs, or ticketing, ship there first. Match the interaction model to the place where action already happens. Then make sure the agent can hand off to humans without losing state or context.\u003C\u002Fp>\u003Cp>If you are building for an enterprise, distribution is part of the architecture. Ignore it and you end up with a technically correct agent nobody touches.\u003C\u002Fp>\u003Ch2>Operate the agent like a system, not a one-off\u003C\u002Fh2>\u003Cblockquote>“Tracing and evaluation for hosted agents and agent optimizer in Foundry Agent Service — a closed loop that turns production failures into ranked, reviewable agent improvements.”\u003C\u002Fblockquote>\u003Cp>This is the part I care about most, because it is where most teams are still improvising. Once an agent is live, you need to know what it did, why it did it, and how to fix it without guessing. If traces stop at the boundary of the model call, you are missing the actual behavior of the system.\u003C\u002Fp>\u003Cp>Microsoft's operating story is tracing plus evaluation plus optimizer. In plain English: capture what happened, score it, and feed the failures back into improvement work. I like the phrase “ranked, reviewable” because it implies humans still get a say. Good. They should. I do not want an optimizer silently rewriting my agent without a paper trail.\u003C\u002Fp>\u003Cp>This is the same lesson I learned with service debugging years ago. If you cannot trace a request end to end, you are not operating a system, you are hoping. Agents make that worse because the model can take multiple branches, call tools, and carry state across time. Without a loop that connects failure to fix, your production bugs become folklore.\u003C\u002Fp>\u003Cp>How to apply it: instrument every meaningful step. Log tool selection, tool input, tool output, memory reads, memory writes, and any branch or retry decision. Build a review queue for bad runs. Then make evaluation part of your release process, not an afterthought. If a prompt, skill, or tool change improves one metric but breaks another, you need to see that before the change ships.\u003C\u002Fp>\u003Cp>My blunt take: if you are not evaluating agents in production-like conditions, you are not ready to call them production agents.\u003C\u002Fp>\u003Ch2>The template you can copy\u003C\u002Fh2>\u003Cpre>\u003Ccode># Agent build spec for Microsoft Foundry-style deployment\n\n## 1) Keep the harness swappable\n- Framework: `Microsoft Agent Framework` \u002F `LangGraph` \u002F `Claude Agent SDK`\n- Business logic lives outside the framework callbacks\n- Prompts, policies, and routing rules live in versioned files\n\n## 2) Define a narrow agent contract\n- Input: task, user context, session ID\n- Output: structured result, tool trace, confidence, next action\n- State: explicit, serializable, resumable\n\n## 3) Normalize tools behind one layer\n- Expose tools through a single catalog or endpoint\n- Version every tool and skill\n- Add tool search or ranking once the catalog grows\n- Keep auth, retries, and governance in the tool layer, not the agent prompt\n\n## 4) Separate memory by lifespan\n- Session memory: current thread only\n- User memory: persistent preferences and facts\n- Procedural memory: repeatable steps and workflow ordering\n\n## 5) Run locally with traces\n- Local execution must show:\n  - tool calls\n  - memory reads\u002Fwrites\n  - branch decisions\n  - retries\n  - final output\n- Debug before deployment, not after\n\n## 6) Deploy to an isolated runtime\n- One session per sandbox\n- Dedicated compute, memory, and filesystem\n- Idempotent retries\n- Durable checkpoints for long-running work\n\n## 7) Publish where users already work\n- Teams\n- Microsoft 365 Copilot\n- Or your product’s primary workflow surface\n\n## 8) Operate with a feedback loop\n- Capture traces in production\n- Review failed runs\n- Score outputs with evaluation sets\n- Feed fixes back into prompts, tools, memory, or routing\n\n## 9) Release checklist\n- [ ] Tool schemas are versioned\n- [ ] Memory boundaries are documented\n- [ ] Local traces match production traces\n- [ ] Runtime isolation is verified\n- [ ] Evaluation runs before and after release\n- [ ] Rollback path exists for prompt, tool, and skill changes\n\n## 10) Copyable project skeleton\n\nagent\u002F\n  prompts\u002F\n    system.md\n    routing.md\n  tools\u002F\n    catalog.yaml\n    schemas\u002F\n  memory\u002F\n    session.md\n    user.md\n    procedural.md\n  eval\u002F\n    golden-cases.json\n    scoring.md\n  runtime\u002F\n    sandbox.md\n    checkpoints.md\n  ops\u002F\n    trace-review.md\n    release-checklist.md\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>I pulled this template from the patterns Microsoft is pushing in the Build 2026 post, but the structure itself is mine. It is a generic agent operating model, not a copy of their product docs. Use it as a starting point, then adapt the framework, tool layer, and runtime to your stack.\u003C\u002Fp>\u003Cp>Source: \u003Ca href=\"https:\u002F\u002Fdevblogs.microsoft.com\u002Ffoundry\u002Fagent-service-build2026\u002F\">Microsoft Foundry Blog post by Tina Schuchman\u003C\u002Fa>. My breakdown is original commentary on top of that source material, with links to the Microsoft docs and related projects cited above.\u003C\u002Fp>","Microsoft Foundry splits build, deploy, and operate so agent frameworks, tools, memory, and runtimes carry into production.","devblogs.microsoft.com","https:\u002F\u002Fdevblogs.microsoft.com\u002Ffoundry\u002Fagent-service-build2026\u002F",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784120662308-flld.png","tools","en","c5d14866-b8a9-41f8-a653-c37b59350ac4",[17,18,19,20,21],"Microsoft Foundry","agent frameworks","toolboxes","memory","agent runtime",[23,24,25],"Foundry pushes the framework choice down and centers runtime, tools, and memory.","Toolboxes and skills aim to reduce integration sprawl around agent actions.","Tracing, evaluation, and isolated runtimes are the missing pieces for production agents.",1,"2026-07-15T13:03:49.567537+00:00","2026-07-15T13:03:49.558+00:00","bb302ca9-ec94-47d3-990b-c59c1f65ea0e",{"tags":31,"relatedLang":32,"relatedPosts":36},[],{"id":15,"slug":33,"title":34,"language":35},"foundry-ship-agents-without-rewrites-zh","Foundry 讓代理不必重寫就上線","zh",[37,43,49,55,61,67],{"id":38,"slug":39,"title":40,"cover_image":41,"image_url":41,"created_at":42,"category":13},"6f7ab80c-abc0-4a66-90a8-52755a624481","databricks-query-foundation-models-guide-en","Databricks lets you query foundation models","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784144058128-58rk.png","2026-07-15T19:33:45.40417+00:00",{"id":44,"slug":45,"title":46,"cover_image":47,"image_url":47,"created_at":48,"category":13},"1a0db5c8-1638-496a-82c2-3c8953ac207a","sglang-inference-is-the-product-en","SGLang is winning because inference is the product","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784140363231-i2js.png","2026-07-15T18:32:19.539863+00:00",{"id":50,"slug":51,"title":52,"cover_image":53,"image_url":53,"created_at":54,"category":13},"dcdffb2f-a2f3-4079-8f6c-cdb2af13cc8e","redmi-note-17-battery-camera-price-breakdown-en","Redmi Note 17 turns mid-range into battery bulk","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784138630965-83b5.png","2026-07-15T18:03:19.453561+00:00",{"id":56,"slug":57,"title":58,"cover_image":59,"image_url":59,"created_at":60,"category":13},"be61d518-74a6-4482-986f-cd0d3bcae472","github-copilot-sdk-lets-apps-run-agents-en","GitHub Copilot SDK lets apps run agents","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784122406117-28v5.png","2026-07-15T13:32:56.664571+00:00",{"id":62,"slug":63,"title":64,"cover_image":65,"image_url":65,"created_at":66,"category":13},"b821ec63-b837-4634-99f0-3b359d3c892f","kimi-k26-turns-prompt-into-brand-sites-en","Kimi K2.6 turns a prompt into brand sites","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784053990583-sulp.png","2026-07-14T18:32:49.279795+00:00",{"id":68,"slug":69,"title":70,"cover_image":71,"image_url":71,"created_at":72,"category":13},"4d4694ff-c317-4c1b-8564-4c310ca8d41b","cloudflare-one-partner-program-ai-security-rollout-en","Cloudflare One partner program speeds AI security rollout","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784037810533-69nw.png","2026-07-14T14:02:57.550961+00:00",[74,79,84,89,94,99,104,109,114,119],{"id":75,"slug":76,"title":77,"created_at":78},"8008f1a9-7a00-4bad-88c9-3eedc9c6b4b1","surepath-ai-mcp-policy-controls-en","SurePath AI's New MCP Policy Controls Enhance AI Security","2026-03-26T01:26:52.222015+00:00",{"id":80,"slug":81,"title":82,"created_at":83},"27e39a8f-b65d-4f7b-a875-859e2b210156","mcp-standard-ai-tools-2026-en","MCP Standard in 2026: Integrating AI Tools","2026-03-26T01:27:43.127519+00:00",{"id":85,"slug":86,"title":87,"created_at":88},"165f9a19-c92d-46ba-b3f0-7125f662921d","rag-2026-transforming-enterprise-ai-en","How RAG in 2026 is Transforming Enterprise AI","2026-03-26T01:28:11.485236+00:00",{"id":90,"slug":91,"title":92,"created_at":93},"6a2a8e6e-b956-49d8-be12-cc47bdc132b2","mastering-ai-prompts-2026-guide-en","Mastering AI Prompts: A 2026 Guide for Developers","2026-03-26T01:29:07.835148+00:00",{"id":95,"slug":96,"title":97,"created_at":98},"3ab2c67e-4664-4c67-a013-687a2f605814","garry-tan-open-sources-claude-code-toolkit-en","Garry Tan Open-Sources a Claude Code Toolkit","2026-03-26T08:26:20.245934+00:00",{"id":100,"slug":101,"title":102,"created_at":103},"66a7cbf8-7e76-41d4-9bbf-eaca9761bf69","github-ai-projects-to-watch-in-2026-en","20 GitHub AI Projects to Watch in 2026","2026-03-26T08:28:09.752027+00:00",{"id":105,"slug":106,"title":107,"created_at":108},"9f332fda-eace-448a-a292-2283951eee71","practical-github-guide-learning-ml-2026-en","A Practical GitHub Guide to Learning ML in 2026","2026-03-27T01:16:50.125678+00:00",{"id":110,"slug":111,"title":112,"created_at":113},"1b1f637d-0f4d-42bd-974b-07b53829144d","aiml-2026-student-ai-ml-lab-repo-review-en","AIML-2026 Is a Bare-Bones Student Lab Repo","2026-03-27T01:21:51.661231+00:00",{"id":115,"slug":116,"title":117,"created_at":118},"6d1bf3f6-e191-4d30-b55b-8a0722fa6afe","ai-trending-github-repos-and-research-feeds-en","AI Trending Tracks Repos and Research Feeds","2026-03-27T01:31:35.709532+00:00",{"id":120,"slug":121,"title":122,"created_at":123},"010539a1-4c3a-4bd3-937a-26616422ee0d","awesome-ai-for-science-research-tools-map-en","Awesome AI for Science Is Becoming a Real Research Map","2026-03-27T01:46:50.89513+00:00"]