You already know about these AI coding

frameworks like BMAD, SpecKit, and

others. But these are not the only ones.

There are hundreds of people

experimenting and launching their own

workflows. But when you try them out,

you'll notice that they often fail to

deliver on their promise. It's not

because their methods are bad. It's

because they don't fit your specific use

case. When we build apps, the majority

of the time, we create our own workflows

instead of relying on pre-made ones.

This is because workflows should be

built around your specific use case and

only work if they align with the project

you're trying to build. So how do you

build a workflow for your own process?

For that you need to know certain

principles. These are the principles

that every framework uses in one way or

another. Before [snorts] discussing the

main principles, it is essential for you

to know what's inside the context window

of these AI tools. It's really important

as managing context is basically what

these frameworks do. The context window

is basically the amount of information

the model can remember at once. Anything

that goes out of the model's context

window goes out of its working memory

and it has no way to recall it. Models

have a limited context window. For

example, anthropic models have a 200k

token context window and Gemini models

have 1 million. Even though these might

look like really big numbers in terms of

the messages you send, they actually are

not that huge. Because in these AI

tools, the context window does not only

consist of your system prompt and user

messages, but also includes a lot of

other things like your past messages,

memory files, tools, MCP calls, and so

on. You need to learn how to make the

most out of this limited working space

so that when you build your workflows,

the model does exactly what you want it

to do. I will be using claude code as my

primary coding tool throughout the

video. But you can build your workflow

with any platform as they all have the

tools needed for these principles. The

most important principle and the key to

any workflow design is progressive

disclosure. That means revealing to the

LLM only what matters and keeping the

model's attention focused on what is

actually needed right now rather than

filling the context window with

everything it might need in the future.

Now, more advanced models like Sonnet

4.5 have a context editing feature built

right in where they can understand

what's noise and try to filter it out on

their own. And they use GP commands to

narrow down what you want. But that

alone is not enough. When we give vague

instructions, even these newer models

load a lot of things that are not needed

and pollute the window. Instead of

asking Claude to fix the error in your

back end, it is better to ask it to

check the end points one by one rather

than asking it to fix everything at

once. The skills feature in Claude is

now open- source and all tools can use

it. Skills are pretty much the

embodiment of progressive disclosure.

Their description provides just enough

information for your AI coding platform

to know when each skill should be used

without loading everything into the

context. A huge mistake people make is

using MCPS for everything. You should

only use MCPS when external data is

required and use skills for everything

else. The second equally important

principle is that information not needed

right now should not belong in the

context window. To achieve this, the

tools use structured note-taking and we

can use this to our advantage by

providing your AI tool with external

files that it can use to document any

decisions, issues or technical debt.

This approach allows your agent to

maintain critical context that might

otherwise be lost when building

something really complex. These tools

also have a compaction feature to manage

the context window. And when the context

resets, you don't have to rely solely on

the compaction summary. For example,

your agent can use these notes to gain

context on what has already been done

and what still needs to be done. This

approach is particularly helpful for

long horizon tasks which are inherently

complex. You might be familiar with the

agent.mmd. It's a standard context file

that all agents read before starting the

session. Some agents don't follow this

and have their own such as the claude.md

and I use them to guide the agent on how

the external files are structured and

what to write in each one of them.

Sometimes these agents randomly pause in

the middle of a longunning task. A lot

of the time this happens because the

context has gone above 70% of its limit.

This is where the concept of attention

budget comes in. Your context window is

what the model pays attention to while

generating output. When it goes over

70%, the model has to focus more and

there's a higher chance of

hallucinations. In terms of AI agents,

it stops them from using their tools

effectively and often times they just

choose to ignore them. To solve this,

there are several built-in tools you can

use. As you already know, compaction

allows the model to start a fresh with a

proper summary of what has happened as

the starting prompt and a reduced

context window. So, instead of letting

it fill up to 90% and triggering the

autocompact feature, try to keep an eye

on the context window and do it

yourself. If you're experimenting, use

Claude's built-in rewind so that you can

delete the unnecessary parts instead of

continuing them and asking Claude for

changes. You should also clear or start

a new context window for any new task so

that the previous context doesn't slow

down the model. Another thing that stems

from the principle of progressive

disclosure is the ability of these

agents to run tasks in the background

without polluting the main context

window. Sub agents work in their own

isolated context window and only report

the output back to the main agent. This

is particularly helpful when working on

tasks that are isolated from each other

because your main context window is

protected from being bloated with the

tool calls and searches that the sub

agent makes, ensuring the information

remains in its dedicated working zone.

Since these agents run in the

background, you can continue interacting

with your main agent and let it work on

something that actually requires your

attention. Whenever I want something

researched, such as the rules of a new

framework that I'm working with, I just

use these sub aents. This way their tool

calls and searches are isolated and they

just return the answer to the main

agent. If you understand the principle

of note takingaking, you should also

know which file format to use for which

task. Since these files have different

formats, they affect the token count and

hence the efficiency of your workflow.

YAML is the most token efficient. So I

mainly use it for database schemas,

security configs, and API details. Its

indentation helps models structure

information properly. Markdown is better

for documentation like your claw.md

because the heading levels make it easy

for the model to navigate between

sections. XML is specifically optimized

for clawed models. Enthropic states that

their models are fine-tuned to recognize

these tags as containers and separators,

which is useful when you have distinct

sections like constraints, summaries, or

visual details. Other models generally

prefer Markdown and YAML over XML. And

lastly, JSON. It's the least token

efficient because of all the extra

braces and quotes. So, I only use it for

small things like task states and don't

really recommend using it for the most

part. Git is one of the most basic

things you're taught when starting

programming. We've seen another trend

with these context workflows in which

people actually use the git commit

history as a reminder to the model of

the progress that's been made, whether

across the whole project or on a single

task. Even if you don't want to use it

to store progress, you should generally

use these context engineering workflows

in a git initialized repository. Having

a context engineering workflow means

that you don't allow the model to do

everything at once, but instead act on

planned steps one by one. If at any

stage you encounter a problem, Git lets

you control which version to revert to

and helps in evaluating which change is

causing problems. People have also

implemented parallelism with Git work

trees. I've also shown plenty of

workflows where sub agents work in

dedicated work trees for parallel work.

Whatever workflow you end up making,

there are always going to be cases where

you end up repeating instructions for

common procedures. A good example is how

you ask the AI tools to do git commits

or update your documentation. In almost

all of these AI tools, there are ways to

reuse your most repeated prompts. I

often use custom/comands in my own

projects because they basically give

Claude a reusable guide. For example, I

often use a catch-up command that

contains instructions on how I structure

memory outside the context window. So

Claude knows how to catch up with the

project instead of reading every file.

They are also good at enforcing

structure. For my commits and

documentation to follow a defined

format, I use a commit/comand that

follows a specific structure for how it

should write commit messages and what

pre-commit checks it should make before

committing. This way, the slash commands

keep everything standardized and I don't

have to instruct Claude again and again

to perform tasks the way I prefer. As

you know, MCPs should be used whenever

external data is required. Jira is the

most widely used team management

software. If you want to get information

from tickets, you can use the Jira MCP.

so it can access tickets directly and

start implementing changes. Similarly, I

use the Figma MCP to provide Claude code

with the app's style guide, which it

then uses to construct the design for

tasks where the model's built-in

capabilities fall short. MCPS are

essential for interacting with external

sources efficiently. You can include

these MCPS directly in your slash

commands so that they become part of

your whole workflow. That brings us to

the end of this video. If you'd like to

support the channel and help us keep

making videos like this, you can do so

by using the super thanks button below.

As always, thank you for watching and

I'll see you in the next one.