This video was one shotted with GPT 5.6 Sol Ultra + Remotion + HeyGen Avatar + ElevenLabs Voice clone.

I’ve been thinking about something adjacent to ICM that I’m calling Context Shaping. ICM makes a lot of sense to me as a way to make agent work visible: files, intermediate artifacts, editable surfaces, and a workflow the human can inspect or participate in. But I keep coming back to another layer that feels separate: Before the agent works, how is the context shaped? In real business workflows, the raw context is messy. It may live across email, calls, meeting notes, documents, spreadsheets, CRM records, support tickets, internal notes, and prior decisions. But I don’t think the answer is to just dump all of that into a giant context window or “business memory.” The harder problem seems to be shaping the right context for the specific workflow step. For example: What should be included? What should be excluded? What should be summarized? What should be redacted? What is only visible to certain roles? What previous decisions matter right now? What context is stale, misleading, or no longer safe to use? What does the agent need to know for this task, without giving it everything? From my point of view, this becomes especially important when agents are operating around real business workflows: handoffs, approvals, follow-up, estimates, customer conversations, internal tasks, project coordination, or anything where the wrong context can create bad decisions. So the distinction I’m playing with is: ICM gives the agent and human a visible workspace. Context Shaping prepares the context pack that enters that workspace. That context pack might include source references, summaries, constraints, permissions, open questions, excluded information, and a record of why certain context was selected. I’m curious if anyone here is thinking about this problem. Are you treating context as something the agent retrieves on its own, or as something that should be deliberately shaped before each workflow step?