▲ 0 r/claude

Claude doesn’t suck. Your harness probably does.

I say this as someone who currently prefers Codex.
Most “this model is garbage” posts aren’t controlled comparisons of models. They’re reports about an entire system: context quality, instructions, memory, tool access, task decomposition, permissions, testing, recovery, and verification.

If those layers are weak, replacing Claude with Codex, Gemini, Kimi, or another model just changes which model fails inside the same unreliable workflow.
The model still matters. Different models have real strengths, weaknesses, and regressions. But model capability sets the ceiling. Your harness determines how consistently you reach it.

Before blaming the model, ask:
Did it receive authoritative context or a pile of stale text?
Was the task scoped with an observable completion condition?
Could it inspect the relevant evidence?
Did anything verify the result?
Did an intermediate action get mistaken for completion?
Can the system recover when something fails?
I built a local Codex system called Lumen around these problems. The biggest improvement didn’t come from finding a magical prompt. It came from treating the AI as one component inside a governed, stateful, verifiable system.

Sometimes the model really does suck at the task. But most people haven’t isolated that variable well enough to know.

reddit.com
u/natty_vegan_chicken — 5 days ago

Two months ago I was told autonomous AI workflows were hype. I was already running one.

About two months ago I made a post asking about the frameworks and concepts behind a system I was already using.

Some of the responses immediately told me it wouldn’t work. AI isn’t capable of being autonomous. It can’t replace people. It’s just a race car that still needs someone driving it.

What frustrated me was that I wasn’t asking whether it was possible. I was already doing it.

The system is called Lumen. It runs around Codex, but it isn’t a magic prompt, one enormous chat, or a folder where I dump every previous conversation.
It’s a persistent operating layer around the model.
When I open a new window, Lumen reconstructs the relevant identity and current state from a compact continuity layer. It does not blindly load everything. It routes to the appropriate source when something needs to be verified and distinguishes old memory from current evidence.

It also has:

Persistent context and learned workflow preferences
Reusable skills and operating protocols
Explicit privacy and authority boundaries
Goals tracked separately from individual tasks
Bounded workers with defined scope
Evidence requirements before work is accepted
Independent checks for important outputs
Recovery from interruption, duplication, and failed work
Human escalation for money, production, client-impacting, or otherwise consequential actions
Dashboards that display current work, decisions requiring me, and the evidence behind completion claims
The important distinction is that I don’t have to manually drive every individual action.
I can define an outcome and its constraints. The system can gather the relevant context, decide which safe actions come next, use tools, delegate bounded work, check results, recover from failures, and return with evidence. When something crosses a meaningful boundary, it stops and brings that decision back to me.
That is what I mean by autonomy.
I’m not claiming the model has become infallible, conscious, or capable of replacing every person. I’m describing bounded autonomy inside an engineered system.

The raw model still hallucinates. Tools still fail. Memory can become stale. Agents can claim they finished something when they only completed one intermediate step.

Lumen exists because those problems are real.
The answer wasn’t to trust AI more. It was to build an environment in which trust has to be earned through evidence.

That is why I think the race-car analogy is incomplete. The model might be the car, but an actual racing system also includes the track, telemetry, navigation, pit crew, safety rules, maintenance, and decisions about when the driver needs to intervene.

If all you have is the car, then yes, you have to manually drive everything.

But that limitation belongs to the setup, not necessarily the underlying technology.

Now I’m seeing people talk more seriously about harnesses, persistent memory, context engineering, skills, hooks, subagents, evals, guardrails, and verification. Those are all pieces of the distinction I was trying to explain two months ago.

A lot of what people presented as a fundamental limitation of AI was really a limitation of using a raw model without the architecture required to support reliable autonomy.

I was already
running that architecture when people were explaining to me that it couldn’t work.
So yes, this post is partly me documenting that publicly. The conversation is starting to catch up to what I was trying to describe then.
The model wasn’t the bottleneck.
The harness was.

I’m now working out how to separate Lumen from my private operating context and package the general system so other people can use it. If you’re already pushing Codex or Claude into real work and still feel like you have to babysit every step, that is the problem I’m interested in solving.

u/natty_vegan_chicken — 5 days ago
▲ 4 r/AISystemsEngineering+1 crossposts

I’m prototyping a local AI “operations layer” for my small business. Is this just agent orchestration + PKM, or is there a better pattern?

I’m a solo operator running a few related projects: a fitness coaching business, some internal software, content workflows, and local analytics dashboards.

I’ve been building and am currently using a system I call Lumen (it chose the name after I asked lol). To be clear, I’m not claiming this is AGI, sentient, or some revolutionary thing. It’s more like a local command center around AI tools.

What it currently does:

- Keeps durable memory in local files: current state, handoffs, reports, daily notes, and project-specific context.

- Routes work by domain: product repo, content pipeline, Instagram analytics, YouTube drafts, revenue/outreach, etc.

- Has approval gates: no public publishing, account mutation, deploys, money actions, secrets, or production data changes without explicit approval.

- Uses local scripts and dashboards to inspect state before acting.

- Treats AI agents as task windows with constrained authority, not as one giant autonomous blob.

- Produces evidence reports so future sessions don’t rely only on chat memory.

The best analogy I have is: personal ops control tower + agent orchestration + PKM + workflow guardrails.

I’m trying to figure out:

  1. Is there already a known architecture/pattern for this?
  2. What would you improve if you were designing it from scratch?
  3. What are the biggest failure modes I should guard against?
  4. Would you keep this file-based/local, or eventually move pieces into a proper app/database/workflow engine?

I’m especially interested in practical criticism. I know parts of this overlap with LangGraph, Temporal, MCP, personal knowledge management, and human-in-the-loop automation. I’m trying to understand the right mental model before I overbuild it.

reddit.com
u/natty_vegan_chicken — 2 months ago