I’m excited to share a new repo: Agent Skills for Context Engineering Instead of just offering a library of black-box tools, it acts as a "Meta-Agent" knowledge base. It provides a standard set of skills, written in markdown and code, that you can feed to an agent so it understands how to manage its own cognitive resources. github.com/muratcankoylan/Ag… Most agent failures are not model failures; they are context failures. This is still an experimental project. The goal is to establish a platform-agnostic standard for context engineering that can be used in Cursor, Claude Code, Copilot or Codex. skills/ context-fundamentals: What context is, why it matters context-degradation: How context fails (lost-in-middle, poisoning) context-optimization: Compaction, masking, caching multi-agent-patterns: Orchestrator, swarm, hierarchical memory-systems: Vector RAG, knowledge graphs, Zep tool-design: Building tools agents can use evaluation: Testing and measuring agent systems I believe this is a good start, showing developers how to approach context engineering rather than relying on ready-made tools. You will also find the aggregated research documents I used to build these skills in the repo. The skills are synthesized from technical blogs on context and prompt engineering that I bookmarked, AI Labs' documentations, and Anthropic Skills examples. Try the 7 Skills, created using Antrhopic's Skills template format. Experiment with the provided scripts and references, and feel free to contribute to the repo.

Ata's hands-on experience on film sets, now shaping how he makes AI ads and movies. Go follow my cousin if you’re working in this space. He shares the creative decisions behind the work. He’s also here with me in Toronto for a while. If you’re around and want to collaborate, hit him up. And if you can help with video model credits, we’ve got plenty of ideas!

When I tried GPT-Live-1 today, I felt deflated as I recognized behaviors we’d spent weeks trying to make reliable. For the past three months, I’ve been focusing on researching and building duplex voice agents, where I wrote thousands of lines across our harness and the experiments around it. Customers use parts of that work every day, the conversions are increasing drastically as we make our voice agents more reliable and expressive. This duplex voice harness/model (interaction runtime + kernel) problem has occupied most of my attention but tbh when I first started working with voice agents, I didn't know how challenging and complex they were. Duplex conversational timing, orchestration, acoustic turn-taking, micro-interruptions, prosody, and generalized noise etc are really hard problems. There are so many 'beautifully crafted"'voice demos but seeing them in production is almost impossible. A cough would interrupt the voice agent, it leaves the caller waiting for it to speak again. During a tool call, someone would change their decision before the earlier result returned. There are also many other telephony factors so it is not just an AI or research problem. Following those cases through the system led us to separate the part that speaks from the work running in the background. We’ve developed a kernel that controls what the agent can do and checks what happened before it reports an outcome to the caller because the duplex models simply weren’t good enough yet. During this period, reading NVIDIA’s PersonaPlex and Nemotron VoiceChat work helped me understand where the models were heading; Thinking Machines’ Interaction Models approach to keeping an interaction going during longer tasks connected with questions we were already working through. My first thought was how much of what I’ve been working on will we no longer need? This is another great example of how harnesses are compressing into models. That's why always build your harness and repo that you can destroy every 6 months and build it from scratch again. It should be very fluid and modular, so you can easily bring the frontier capabilities. That's why building a duplex harness that happens to use ASR, STT, LLM, TTS models is not a good solution since duplex is commoditized today. Build a harness where the duplex model itself is a replaceable component. This is valid for any software field. After spending months with these problems, I appreciate the work behind GPT-Live more deeply. Through client delegation, anyone can connect GPT-Live to existing harnesses, where the models you choose work with your tools. Thank you to the OpenAI team. This is a big win for anyone building solutions to benefit humanity.

Another good open source resource find: nitter.cf/mitchellhynes/status/2…

also starting a new side project. I’m coming into hardware with basically zero experience, so I ran GPT-5.6 Sol Ultra with my background, goals, and setup and had it build a personalized research + learning roadmap. It’s designed for me, but a lot of the research, weekly builds, project ideas, etc should be useful to anyone trying to move from software into hardware with an embodied ai focus github.com/muratcankoylan/Ma…

Don’t make the model solve the entire complex problem. Make the harness turn the complex problem into a collection of simple problems. 1. Start with the dumbest system that can work. 2. Build a good eval. 3. Add complexity only where the eval shows that you need it. I love these Netflix AI blogs because their engienering decisions explain not just what worked, but what they deliberately chose not to build. Synopsis evaluator is a great example of measuring the failure, then adding the smallest amount of complexity needed to fix it. netflixtechblog.com/evaluati…

Thank you for supporting open source @sama

Prompt engineering for long running agents is the solution: nitter.cf/muratcan/status/207667… - What & How to build - How to analyze and evaluate - What makes it ready LLMs are inherently lazy; you need to make them work until the task is complete entirely.

When building harnesses, don’t design only for what today’s models can do. Anticipate where they’ll be in six months, and build your architecture for that trajectory. Harnesses are becoming models, and Voice AI is about to have its moment. I believe it will significantly accelerate AI adoption very soon. I've been working with my team at Sully on duplex and half cascade voice architectures recently. The thinking of most researchers and AI labs working on Voice AI is converging around these ideas: - A continuously active, full-duplex speech model owns the conversational floor. - Media is isolated from application logic. - Deeper reasoning and tools run asynchronously. - The live model can sustain the interaction while slower work runs. - Application state and discrete records are derived without forcing the media path back into request/response turns. The realtime front can own timing, prosody, interruptions, acknowledgements, and conversational repair. But for tasks that require tool calls or deeper reasoning, you still need a harness. You build the realtime model on top of that harness. Our research partners at NVIDIA also shared this open-source model today: huggingface.co/nvidia/NVIDIA… NVIDIA's VoiceChat-11B shows that turn-taking, interruption handling, streaming speech understanding, speech generation, tool selection, and tool-wait narration are all being trained into a single model. But I still strongly believe that a deterministic harness remains essential. You cannot build reliable voice experiences using only a realtime model, just as you cannot build truly smooth voice experiences with full cascaded systems alone. The model reports 82.5% tool-selection accuracy, but only 44.2% argument accuracy and 33% Pass@1 on Full-Duplex-Bench v3. You cannot put a model alone in front of people especially in high-risk industries. The conversational harness is moving into the model; the transactional harness is not. In Voice AI, your harness should simplify its caller-facing recovery machinery as continuous models absorb floor control. At the same time, it should add stronger asynchronous task and state-management mechanisms behind the front. Continuous models make the backend harness even more important. The front can now speak while state is provisional, receive new intent while old work is still running, overlap speech with tool completion, and generate plausible progress or outcome language before a transaction has actually settled. Application orchestration is not obsolete. The interaction control loop is becoming a learned, continuous capability.