How are you actually deciding what context an agent should see at each step?
Not just “use RAG” or “increase the context window” — I mean things like task state, previous tool calls, memory, retrieved documents, conversation history, failed attempts, etc.
Do you have an actual context selection/pruning strategy, or are you mostly throwing everything into the prompt and relying on the model to figure it out?
Curious what people are doing in production, especially with long-running agents.

How are you actually deciding what context an agent should see at each step?
Not just “use RAG” or “increase the context window” — I mean things like task state, previous tool calls, memory, retrieved documents, conversation history, failed attempts, etc.
Do you have an actual context selection/pruning strategy, or are you mostly throwing everything into the prompt and relying on the model to figure it out?
Curious what people are doing in production, especially with long-running agents.

I am experimenting with an agent architecture that is less “give the model a big prompt and trust its reasoning” and more like a controlled belief-and-decision loop.

Not claiming it literally mimics the human brain. More that it borrows a useful pattern: maintain competing explanations, update beliefs from evidence, decide what to check next, then act based on consequences.

Very simple example: a smart-fridge agent gets a “weird smell” signal.

Possible worlds:

• someone spilled mango juice
• an egg is rotting
• fridge power failed and food is warming
• some other cause we did not model

It starts with priors based on context: recent door-open events, temperature history, what food is inside, past failures, etc.

Then it gets evidence. Say the temperature sensor reads 14°C.

Instead of the LLM narrating “this seems concerning,” the system asks:

• How likely is 14°C under each world?
• Update prior → posterior using those likelihoods.
• How much uncertainty actually reduced? Entropy before vs. after.
• Which allowed question has the highest expected information gain next? For example, “is the compressor drawing power?” is probably much more useful than “what color is the fridge magnet?”
• Is that question worth its cost, latency, privacy impact, and reliability?
• Given the posterior plus action costs, should it notify the user, wait, run another check, or escalate to a human?

The LLM can help extract signals, propose candidate hypotheses, and call tools, but it should not be the final authority over belief updates or actions. The controller owns the world list, priors, likelihood estimates, policy thresholds, logs, and escalation rules.

Important parts I want to keep explicit:

• an “other / unknown world” bucket, so the system does not act like its hypothesis list is complete
• calibrated probabilities and provenance for priors/likelihoods
• expected value of information, not just entropy reduction
• a human escalation path when uncertainty remains high, the case is out-of-distribution, or the downside is asymmetric
• a trace showing whether failure came from missing worlds, stale priors, bad likelihoods, a bad question policy, or bad action costs

The rough loop is:

input → possible worlds → prior → evidence likelihoods → posterior → uncertainty / expected information gain → cost-aware action → human escalation if needed → outcome + calibration update

Math/AI people: is this a sensible practical architecture, or am I reinventing POMDPs, active inference, Bayesian decision networks, belief-state planning, etc. badly?

What would you change first to make this real and evaluable? Especially interested in:

1. handling open-world hypotheses,
2. learning/calibrating likelihoods without pretending the numbers are objective,
3. separating “most informative question” from “question that most improves the actual decision.”

I am experimenting with an agent architecture that is less “give the model a big prompt and trust its reasoning” and more like a controlled belief-and-decision loop.

Not claiming it literally mimics the human brain. More that it borrows a useful pattern: maintain competing explanations, update beliefs from evidence, decide what to check next, then act based on consequences.

Very simple example: a smart-fridge agent gets a “weird smell” signal.

Possible worlds:

• someone spilled mango juice
• an egg is rotting
• fridge power failed and food is warming
• some other cause we did not model

It starts with priors based on context: recent door-open events, temperature history, what food is inside, past failures, etc.

Then it gets evidence. Say the temperature sensor reads 14°C.

Instead of the LLM narrating “this seems concerning,” the system asks:

• How likely is 14°C under each world?
• Update prior → posterior using those likelihoods.
• How much uncertainty actually reduced? Entropy before vs. after.
• Which allowed question has the highest expected information gain next? For example, “is the compressor drawing power?” is probably much more useful than “what color is the fridge magnet?”
• Is that question worth its cost, latency, privacy impact, and reliability?
• Given the posterior plus action costs, should it notify the user, wait, run another check, or escalate to a human?

The LLM can help extract signals, propose candidate hypotheses, and call tools, but it should not be the final authority over belief updates or actions. The controller owns the world list, priors, likelihood estimates, policy thresholds, logs, and escalation rules.

Important parts I want to keep explicit:

• an “other / unknown world” bucket, so the system does not act like its hypothesis list is complete
• calibrated probabilities and provenance for priors/likelihoods
• expected value of information, not just entropy reduction
• a human escalation path when uncertainty remains high, the case is out-of-distribution, or the downside is asymmetric
• a trace showing whether failure came from missing worlds, stale priors, bad likelihoods, a bad question policy, or bad action costs

The rough loop is:

input → possible worlds → prior → evidence likelihoods → posterior → uncertainty / expected information gain → cost-aware action → human escalation if needed → outcome + calibration update

Math/AI people: is this a sensible practical architecture, or am I reinventing POMDPs, active inference, Bayesian decision networks, belief-state planning, etc. badly?

What would you change first to make this real and evaluable? Especially interested in:

1. handling open-world hypotheses,
2. learning/calibrating likelihoods without pretending the numbers are objective,
3. separating “most informative question” from “question that most improves the actual decision.”

I'm curious about what happens after a coding agent makes a wrong move. Do you have an actual recovery mechanism checkpoints, rollback, retry with different context, supervisor escalation, handoff to another agent, etc.? What actually reduced recovery time in practice? I'm less interested in preventing every mistake and more interested in making failure cheap.

I’m curious about the different harnesses people have built around coding agents, especially the weird/custom ones that go beyond just CLAUDE.md / AGENTS.md and a few prompts. Are you using hooks that actually block actions, separate planning/review agents, sandboxed environments, cross-model review (Claude → Codex or vice versa), eval loops, context/memory systems, automatic rollback, task routers, observability, etc.? I’m much more interested in the stuff you’ve actually found useful in practice than the standard “give the agent good instructions” advice what does your harness look like, and what has genuinely increased the productivity/reliability of your agents? what tools or practices turned out to be a waste of time?

Has anyone else felt like they’ve designed what seems like a solid architecture using AI tools, and then harnessed it through coding agents like Claude Code/Codex — only to realize the project is moving so fast that you’re starting to lose comprehension of what’s actually being built?

I’ll be honest: I don’t really care about every line of code being written. I care about the architecture, the engineering decisions, and whether the system actually works.

But that’s where I’m struggling.
How do you maintain engineering discipline when AI can generate and modify code much faster than you can realistically review and understand every change?

How do you make sure you’re not just building AI slop on top of what initially looked like a great architecture?

I’ve been thinking about loop engineering as a solution, but I’m starting to feel like it isn’t enough. We build → observe bottlenecks → tweak the architecture → build again → discover new bottlenecks → repeat.

At some point, the architecture itself keeps evolving faster than your mental model of the system.
So I’m curious about people actually building serious systems with coding agents:

How do you maintain engineering discipline and architectural integrity when the code generation is moving faster than your ability to comprehend the entire codebase?

And am I misunderstanding loop engineering here? Is continuously iterating on the system actually the right answer, or is there another discipline/practice that keeps agent-assisted development from turning into AI slop?

Would genuinely love to hear from people who are dealing with this in production, not just building demos.

I do know the obvious answer is to slow down, read the code, and build incrementally. But when the whole point of these tools is to massively accelerate the feedback loop, is there a better engineering practice that lets us keep that velocity without sacrificing understanding and discipline?

Has anyone else felt like they’ve designed what seems like a solid architecture using AI tools, and then harnessed it through coding agents like Claude Code/Codex — only to realize the project is moving so fast that you’re starting to lose comprehension of what’s actually being built?

I’ll be honest: I don’t really care about every line of code being written. I care about the architecture, the engineering decisions, and whether the system actually works.

But that’s where I’m struggling.
How do you maintain engineering discipline when AI can generate and modify code much faster than you can realistically review and understand every change?

How do you make sure you’re not just building AI slop on top of what initially looked like a great architecture?

I’ve been thinking about loop engineering as a solution, but I’m starting to feel like it isn’t enough. We build → observe bottlenecks → tweak the architecture → build again → discover new bottlenecks → repeat.

At some point, the architecture itself keeps evolving faster than your mental model of the system.
So I’m curious about people actually building serious systems with coding agents:

How do you maintain engineering discipline and architectural integrity when the code generation is moving faster than your ability to comprehend the entire codebase?

And am I misunderstanding loop engineering here? Is continuously iterating on the system actually the right answer, or is there another discipline/practice that keeps agent-assisted development from turning into AI slop?

Would genuinely love to hear from people who are dealing with this in production, not just building demos.

I do know the obvious answer is to slow down, read the code, and build incrementally. But when the whole point of these tools is to massively accelerate the feedback loop, is there a better engineering practice that lets us keep that velocity without sacrificing understanding and discipline?

Has anyone else felt like they’ve designed what seems like a solid architecture using AI tools, and then harnessed it through coding agents like Claude Code/Codex only to realize the project is moving so fast that you’re starting to lose comprehension of what’s actually being built?

I’ll be honest: I don’t really care about every line of code being written. I care about the architecture, the engineering decisions, and whether the system actually works.

But that’s where I’m struggling.
How do you maintain engineering discipline when AI can generate and modify code much faster than you can realistically review and understand every change?

I do know the obvious answer is to slow down, read the code, and build incrementally. But when the whole point of these tools is to massively accelerate the feedback loop, is there a better engineering practice that lets us keep that velocity without sacrificing understanding and discipline?

How do you make sure you’re not just building AI slop on top of what initially looked like a great architecture?

I’ve been thinking about loop engineering as a solution, but I’m starting to feel like it isn’t enough. We build → observe bottlenecks → tweak the architecture → build again → discover new bottlenecks → repeat.

At some point, the architecture itself keeps evolving faster than your mental model of the system.
So I’m curious about people actually building serious systems with coding agents:

How do you maintain engineering discipline and architectural integrity when the code generation is moving faster than your ability to comprehend the entire codebase?

And am I misunderstanding loop engineering here? Is continuously iterating on the system actually the right answer, or is there another discipline/practice that keeps agent-assisted development from turning into AI slop?

Would genuinely love to hear from people who are dealing with this in production, not just building demos.

Hot take: most “agentic” systems are not agents.

They are a language model wearing a tool belt, walking directly from vibes to side effects.

user request
→ LLM says “probably X”
→ calls tool
→ something irreversible happens

That is not reasoning under uncertainty.

That is autocomplete with a loaded Nerf gun. Sometimes it is a real gun.

The missing layer is probability, but not the “model said 92% confident” cosplay version.

I mean an architecture that separates:

Reality        = what is actually true
Observations   = logs, documents, tool output, user input
Belief         = what the evidence currently supports
Action         = what the system is allowed to do

An LLM is useful inside this system. It can read unstructured traces, propose hypotheses, reformulate retrieval queries, select candidate probes, and explain the final result.

It should not be judge, jury, calculator, and production deploy button.

Here is the architecture I wish more agent diagrams had:

raw request / traces / documents
  → parsers + LLM interpretation
  → typed evidence record
  → belief state over hidden causes
  → Bayesian update
  → candidate probes from LLM + tools
  → information-value / cost / permission policy
  → act / ask / hold / escalate
  → outcome logging, calibration, drift monitoring

The math is not academic garnish

Suppose a production trace fails. The true root cause is hidden.

Possible causes:
- malformed tool payload
- upstream dependency timeout
- retrieval context overflow
- permission failure

The agent should hold a belief distribution:

P(cause | evidence)

A new clue arrives: schema validation failed.

Update the belief:

posterior ∝ likelihood × prior
P(H | E) ∝ P(E | H) × P(H)

The LLM can say, “Schema mismatch looks plausible.”

Fine. That is a hypothesis.

The system still needs to ask:

How common is schema failure in this service?
How likely is this clue under each competing cause?
Is the input evidence trustworthy?
What action is permitted if the hypothesis is wrong?

Because:

P(clue | cause) ≠ P(cause | clue)

Yes, that old Bayes line still ruins bad demos for a living.

The part people skip: each uncertainty has a different shape

Not every unknown gets to be called “confidence.”

Agent question	Useful model	Why
“Is this evidence sufficient?”	Bernoulli	One yes/no event
“Which root cause is live?”	Categorical	Several competing causes
“How many of 500 cases need review?”	Binomial	Fixed batch, count of yes outcomes
“How many incidents arrive this hour?”	Poisson	Arrival count over time
“Will a reviewer respond before 15 minutes?”	Exponential or survival model	Waiting-time risk
“Is this sensor reading abnormal?”	Gaussian or empirical baseline	Continuous measurement

This is not distribution-collector behaviour.

It changes the decision.

Example:

P(reviewer completes within 15 minutes) = 18%
Benefit of timely review = ₹12,000
Cost of waiting + review = ₹3,000

Net value = 0.18 × ₹12,000 - ₹3,000
          = -₹840

Correct move:

Hold the risky action now.
Escalate through the emergency path.
Do not sit around waiting for a human-shaped miracle.

Information gain is also not enough

A probe can reduce uncertainty and still have zero operational value.

If every possible probe result still forces “hold,” then the probe may be intellectually satisfying but operationally pointless.

The real question is value of information:

Will this evidence improve the eventual decision
enough to justify its cost?

Cost includes:

money
latency
compute
privacy
permissions
human attention
opportunity cost

So the policy is:

Ask if expected decision improvement > full probe cost.
Stop when no permitted probe is worth buying.

The LLM’s actual role

LLM:
- interpret messy text
- propose hypotheses
- generate candidate probes
- synthesize evidence
- explain the receipt

System:
- validate structure
- maintain calibrated beliefs
- enforce permissions
- calculate risk/cost/deadline tradeoffs
- choose and execute allowed actions
- learn from confirmed outcomes

The LLM is the investigator and translator.

The rest of the architecture is the chain of custody, calculator, and safety officer.

If your agent’s only safety mechanism is:

“Be careful.”

Congratulations. You have written a motivational poster for a stochastic parrot.

Build the belief state. Type the uncertainty. Price the next question. Enforce the policy. Log the outcome.

Then you have an agent worth trusting near production.

I’m experimenting with an agent that receives a failed execution trace and tries to work out what went wrong.

One thing I don’t want to do is just dump the entire trace into another LLM and ask "find the problem."

I’m more interested in letting it inspect evidence step by step and decide what to check next.

Has anyone tried something similar? Curious what worked and what completely failed.

I’m working on a project around agent debugging.

Say a LangGraph agent fails after 10–15 steps. You have the trace, tool calls and outputs, but the real cause is not obvious.

How do you normally investigate it?

Do you start from the failed step and move backwards, inspect tool outputs, replay calls, check state, or something else?

Trying to understand what people actually do in production before I design anything.