noonez

ai | opinions | polymarket

dm open

all what I post DYOR

[noonez @0xnoonez]

https://t.co/F4eqoSAcLg

[noonez @0xnoonez]

this paper is f*cking gold

most people are still trying to build better agents by improving the model

but the model is only one piece of the system

a production agent actually depends on five different control layers:

Loop → Graph → Harness → Context → Memory

the loop decides when execution should continue

the graph decides where execution goes next

the harness decides what the agent is allowed to touch

context decides what the model can see right now

memory decides what survives into the next run

once you separate these five layers, agent architecture starts making way more sense

better models don't fix broken systems

better control does

bookmark this before it disappears from your feed

then read the full Agent Engineering breakdown below

[noonez @0xnoonez]

@whoyatagarasu good research, love it

[noonez @0xnoonez]

this paper is f*cking gold

most people are still trying to build better agents by improving the model

but the model is only one piece of the system

a production agent actually depends on five different control layers:

Loop → Graph → Harness → Context → Memory

the loop decides when execution should continue

the graph decides where execution goes next

the harness decides what the agent is allowed to touch

context decides what the model can see right now

memory decides what survives into the next run

once you separate these five layers, agent architecture starts making way more sense

better models don't fix broken systems

better control does

bookmark this before it disappears from your feed

then read the full Agent Engineering breakdown below

[noonez @0xnoonez]

https://t.co/F4eqoSAcLg

[noonez @0xnoonez]

this is f*cking gold

everyone is trying to give AI agents more memory

but almost nobody is engineering what the agent should actually remember

this breaks it into four different memory systems:

Working → Episodic → Semantic → Procedural

one holds the current task

one remembers what happened before

one keeps learned facts

one preserves reusable ways of doing things

I started thinking about agent memory this way and the architecture immediately made more sense.

because the goal isn't to make an agent remember everything.

it's to make the right memory available at the right moment.

that's the difference between storing context

and engineering memory.

bookmark this before it disappears from your feed.

then read the full Memory Engineering breakdown below. 👇

[noonez @0xnoonez]

this is f*cking gold

everyone is trying to give AI agents more memory

but almost nobody is engineering what the agent should actually remember

this breaks it into four different memory systems:

Working → Episodic → Semantic → Procedural

one holds the current task

one remembers what happened before

one keeps learned facts

one preserves reusable ways of doing things

I started thinking about agent memory this way and the architecture immediately made more sense.

because the goal isn't to make an agent remember everything.

it's to make the right memory available at the right moment.

that's the difference between storing context

and engineering memory.

bookmark this before it disappears from your feed.

then read the full Memory Engineering breakdown below. 👇

[noonez @0xnoonez]

https://t.co/F4eqoSAcLg

[noonez @0xnoonez]

Google just released a free 42-minute course on GraphRAG.

most people think better RAG is all about better embeddings.

Google shows retrieval is much bigger than that.

06:18 - where vector search starts to fail

13:40 - how to scale retrieval across large knowledge bases

23:01 - combine keyword and semantic search

31:06 - rank hybrid results without blending incompatible scores

37:14 - use GraphRAG to retrieve connected knowledge instead of isolated chunks

the progression looks like this:

Keywords → Vectors → Hybrid Search → GraphRAG → Grounded Agents

most RAG pipelines stop after finding similar chunks.

the next generation retrieves relationships, not just documents.

vector search was the first step.

graph-powered retrieval is what comes next.

this free 42-minute course contains more practical GraphRAG knowledge than most paid RAG courses.

watch it, then read the full GraphRAG guide below. 👇

[noonez @0xnoonez]

your agent is rarely the model itself

the model generates a single decision.

everything after that is controlled by the system around it.

LOOP vs GRAPH

every response passes through three independent layers.

LOOP ENGINEERING

owns time.

it decides whether execution should continue, retry, stop, or escalate.

it owns retries, budgets, progress checks, evaluator thresholds, and exit conditions.

if the agent keeps spending turns without making progress, the problem is usually the loop.

build execution that can recover without running forever.

GRAPH ENGINEERING

owns state.

it decides which transition is valid and what context carries forward.

it owns routing, branches, joins, checkpoints, recovery, and resumability.

if execution reaches the wrong state, the problem isn't the prompt.

make the workflow explicit instead of relying on the model.

LOOP controls time.

GRAPH controls state.

the model makes a proposal.

the architecture determines what actually happens.

[kerazcity @0xkerazcity]

https://t.co/u1CJGMpcLa

[noonez @0xnoonez]

Anthropic just showed how AI agents can maintain their own memory.

give an agent enough time and its memory fills with duplicate facts, outdated information, and noisy retrieval.

eventually it starts trusting memories that should have been forgotten.

their solution works almost like sleep:

- spawn a sub-agent for each transcript
- verify which facts are still true
- merge duplicate memories
- rebuild the memory index in the background

the agent keeps working while its memory quietly reorganizes itself.

the clever part is the cost.

around 95% of the work comes from cached computation, making continuous memory maintenance practical.

the breakthrough isn't perfect memory.

it's knowing what to forget.

an agent is only as reliable as the memories it still trusts months later.

[noonez @0xnoonez]

@ScottyBeamIO pretty hardwork to create this kind of robot that makes 25k per month

[noonez @0xnoonez]

Google just released a free 42-minute course on GraphRAG.

most people think better RAG is all about better embeddings.

Google shows retrieval is much bigger than that.

06:18 - where vector search starts to fail

13:40 - how to scale retrieval across large knowledge bases

23:01 - combine keyword and semantic search

31:06 - rank hybrid results without blending incompatible scores

37:14 - use GraphRAG to retrieve connected knowledge instead of isolated chunks

the progression looks like this:

Keywords → Vectors → Hybrid Search → GraphRAG → Grounded Agents

most RAG pipelines stop after finding similar chunks.

the next generation retrieves relationships, not just documents.

vector search was the first step.

graph-powered retrieval is what comes next.

this free 42-minute course contains more practical GraphRAG knowledge than most paid RAG courses.

watch it, then read the full GraphRAG guide below. 👇

[Anatoli Kopadze @AnatoliKopadze]

https://t.co/eq0oL4fIaR

[noonez @0xnoonez]

everyone talks about loops and graphs.

almost nobody separates the three layers that actually make an agent work.

they all surround the same model, but they solve different problems.

HARNESS ENGINEERING

defines the execution environment.

- tools, memory, permissions, sandboxes
- context management and observability

the same model behaves differently because the environment around it changes.

LOOP ENGINEERING

defines the feedback cycle.

- run the model
- inspect the result
- call tools
- inject new evidence
- repeat only when necessary

retry because the evidence changed.

not because the model thinks it's finished.

GRAPH ENGINEERING

defines the workflow.

- nodes represent execution steps
- edges define valid transitions
- supports branching, parallel execution, joins, and human approval points

use a graph when execution order actually matters.

how they fit together:

- the harness provides the environment
- the graph defines the workflow
- the loop drives progress inside the workflow

when something breaks, debug the right layer:

- lost memory or missing tools → harness
- no retry after failure → loop
- execution follows the wrong path → graph

most agent failures aren't model failures.

they're architecture failures.

[noonez @0xnoonez]

Anthropic just showed how AI agents can maintain their own memory.

give an agent enough time and its memory fills with duplicate facts, outdated information, and noisy retrieval.

eventually it starts trusting memories that should have been forgotten.

their solution works almost like sleep:

- spawn a sub-agent for each transcript
- verify which facts are still true
- merge duplicate memories
- rebuild the memory index in the background

the agent keeps working while its memory quietly reorganizes itself.

the clever part is the cost.

around 95% of the work comes from cached computation, making continuous memory maintenance practical.

the breakthrough isn't perfect memory.

it's knowing what to forget.

an agent is only as reliable as the memories it still trusts months later.

[seeco @seeconvm]

https://t.co/mm6Jy6Ofzu

[noonez @0xnoonez]

everyone keeps fixing the prompt

when the real problem is usually the architecture around it

a prompt only describes what the agent should do.

everything after that is controlled by the system.

three layers decide whether the job succeeds:

loop engineering

- controls how long the agent keeps working
- decides when another attempt is worth making
- manages retries, budgets, and stopping conditions

if the agent keeps spinning without making progress, the loop is broken

graph engineering

- controls how execution moves through the workflow
- decides which state comes next
- manages routing, branching, checkpoints, and recovery

if the workflow reaches the wrong state, the graph is broken

harness engineering

- controls how the agent interacts with the outside world
- limits tools, permissions, and side effects
- enforces sandboxes, evaluations, and approvals

if the workflow performs an action it shouldn't, the harness is broken

don't rewrite the prompt to solve architectural problems.

fix the layer that's actually failing.

the prompt defines the objective.

the architecture determines the outcome.

[noonez @0xnoonez]

everyone talks about loops and graphs.

almost nobody separates the three layers that actually make an agent work.

they all surround the same model, but they solve different problems.

HARNESS ENGINEERING

defines the execution environment.

- tools, memory, permissions, sandboxes
- context management and observability

the same model behaves differently because the environment around it changes.

LOOP ENGINEERING

defines the feedback cycle.

- run the model
- inspect the result
- call tools
- inject new evidence
- repeat only when necessary

retry because the evidence changed.

not because the model thinks it's finished.

GRAPH ENGINEERING

defines the workflow.

- nodes represent execution steps
- edges define valid transitions
- supports branching, parallel execution, joins, and human approval points

use a graph when execution order actually matters.

how they fit together:

- the harness provides the environment
- the graph defines the workflow
- the loop drives progress inside the workflow

when something breaks, debug the right layer:

- lost memory or missing tools → harness
- no retry after failure → loop
- execution follows the wrong path → graph

most agent failures aren't model failures.

they're architecture failures.

[Lunar @LunarResearcher]

https://t.co/eflBjoVyV2

[noonez @0xnoonez]

your prompt is not your agent architecture

the prompt defines intent.

the system decides what happens next.

after every model response, three layers take control:

loop engineering:

- turns intent into bounded execution
- decides whether another attempt is justified
- owns retries, budgets, and exit conditions
- if the agent keeps repeating work, fix the loop

graph engineering:

- turns actions into a stateful workflow
- decides the next valid state and execution path
- owns routing, branches, checkpoints, and recovery
- if execution reaches the wrong state, fix the graph

harness engineering:

- turns tool access into controlled execution
- decides which actions are actually allowed
- owns permissions, sandboxes, evals, and approvals
- if the workflow creates unsafe side effects, fix the harness

rewrite the prompt when intent is wrong.

fix the loop when work repeats.

fix the graph when state diverges.

fix the harness when execution escapes.

the prompt proposes.

the architecture decides.

[noonez @0xnoonez]

everyone keeps fixing the prompt

when the real problem is usually the architecture around it

a prompt only describes what the agent should do.

everything after that is controlled by the system.

three layers decide whether the job succeeds:

loop engineering

- controls how long the agent keeps working
- decides when another attempt is worth making
- manages retries, budgets, and stopping conditions

if the agent keeps spinning without making progress, the loop is broken

graph engineering

- controls how execution moves through the workflow
- decides which state comes next
- manages routing, branching, checkpoints, and recovery

if the workflow reaches the wrong state, the graph is broken

harness engineering

- controls how the agent interacts with the outside world
- limits tools, permissions, and side effects
- enforces sandboxes, evaluations, and approvals

if the workflow performs an action it shouldn't, the harness is broken

don't rewrite the prompt to solve architectural problems.

fix the layer that's actually failing.

the prompt defines the objective.

the architecture determines the outcome.

[seeco @seeconvm]

https://t.co/mm6Jy6Ofzu

[noonez @0xnoonez]

i turned Claude into an entire company

instead of one assistant, it now works like a real organization with specialized teams

developers:

- Superpowers
- Context7
- Skill Creator
- MCP Builder
- Webapp Testing
- Claude-Mem

design:

- UI UX Pro Max
- Taste
- Frontend Design
- Transitions
- Web Artifacts
- Brand Guidelines

marketing:
- 45 skills for copywriting, SEO, campaigns, and lead generation

social media:
- 17 skills for posts, reels, thumbnails, and content pipelines

finance:
- 8 skills for accounting, reconciliation, audits, and reporting

small business:
- 31 skills for payroll, invoicing, cash flow, and operations

legal:
- 9 skills for contracts, NDAs, and compliance

this isn't a prompt library.

it isn't another wrapper around Claude.

it's a modular operating system where every department has its own responsibilities, workflows, and expertise.

if you know any great skill repositories worth adding, drop them below and i'll include them in v2.

[noonez @0xnoonez]

your prompt is not your agent architecture

the prompt defines intent.

the system decides what happens next.

after every model response, three layers take control:

loop engineering:

- turns intent into bounded execution
- decides whether another attempt is justified
- owns retries, budgets, and exit conditions
- if the agent keeps repeating work, fix the loop

graph engineering:

- turns actions into a stateful workflow
- decides the next valid state and execution path
- owns routing, branches, checkpoints, and recovery
- if execution reaches the wrong state, fix the graph

harness engineering:

- turns tool access into controlled execution
- decides which actions are actually allowed
- owns permissions, sandboxes, evals, and approvals
- if the workflow creates unsafe side effects, fix the harness

rewrite the prompt when intent is wrong.

fix the loop when work repeats.

fix the graph when state diverges.

fix the harness when execution escapes.

the prompt proposes.

the architecture decides.

[rvaniaaa @rvaniaaaa]

https://t.co/CVQKUEKoiW

[noonez @0xnoonez]

Claude Code creator Boris Cherny just shared what comes after prompt engineering.

In this 30-minute talk, he explains the five shifts that turn prompts into production-ready AI systems:

03:38 - remove most of the system prompt

06:55 - evolve CLAUDE.md instead of rewriting prompts

17:44 - refactor an entire codebase from a single prompt

21:59 - keep an agent running for 15 days

25:27 - coordinate 1,000 agents from just two prompts

most people are still optimizing prompts.

Boris is optimizing the entire execution stack:

Context → Planning → Execution → Verification → Multi-Agent Coordination

prompts start the work.

orchestration finishes it.

this free talk contains more practical agent engineering than most paid courses.

bookmark it, watch it, then read the complete agent orchestration guide below.