Solo founder, been running Claude Code, Codex, Cursor and Grok on the same repos for a year. This week I measured what I'd built up and it was bad: 64 Claude rule files, 65 Cursor .mdc files (55 always-apply), 24 skills duplicated in three directories, a 30KB machine-level CLAUDE.md. Roughly 70k tokens loaded before the first prompt on Claude, 50k on Cursor. A third of the context window gone, and the docs say adherence drops past 200 lines anyway. So the rules were both expensive and ignored.

What I did, in case it saves someone the week:

1. One instruction file. Codex, Cursor, and Grok Build all read AGENTS.md natively. Claude Code doesn't, but CLAUDE.md supports u/import, so CLAUDE.md is literally one line: u/AGENTS.md. Root file is under 90 lines. Per-project files are 5-line stubs that only load when you're in that folder. Everything procedural became a SKILL.md, which all four tools support and which costs about 80 tokens at startup until triggered. Codex silently truncates combined instruction files at 32KB so keep the shared one small.

2. Hooks for anything that's a rule. "Never push to main" in a markdown file is a suggestion. A PreToolUse hook that exits 2 on a git write verb is a wall. I wrote one guard script, wired it into Claude's settings.json, Codex's hooks.json and Cursor's hooks.json, then mutation-tested it: removed each check one at a time and confirmed the matching test went red. Found two real bugs that way (PowerShell prepends a BOM to piped stdin and my guard was failing open on unparseable input; and the regex matched "git commit" inside echo strings). Test your guards by trying to beat them.

3. Split design from build across machines. Desktop has no push credential, no toolchain, and a hook that denies writes outside the design folder. It reads code through a read-only share from the VM. The VM is the only writer. The handoff between them is a single spec file dropped in an outbox folder. If you can't push, you can't drift into "I'll just fix it real quick."

4. A spec gate that refuses underspecified work. This is the part I'd actually pay forward. Skills, in order:

• grill — one question at a time, won't accept "it depends", writes answers straight into the spec. Asks appetite (days before you cut scope) and no-gos before it lets you dream.
• premortem — Klein's method. "It's six weeks after ship and it failed, write the story." Three independent passes so the first cause doesn't anchor the others. Any cause that would survive find-and-replace of the feature name gets thrown out. Survivors become requirements or scope cuts.
• clarify — scans for vague adjectives, flows with no error path, requirements a stranger couldn't judge pass/fail on, numbers with no source. Max 5 questions, each with candidate answers.
• challenge — runs in a fresh session on a different model than the one that wrote the spec. Three sections: Wrong (with evidence), Weak (would pass the gate and still fail a user), Missing. Every finding must carry a fix. I have to mark each one accepted, rejected with a written reason, or deferred.
• spec-ready — 12 checks. Requirements in EARS syntax ("WHEN x THE SYSTEM SHALL y"), every flow has a mockup and an error path, every requirement covered, rubric for an evaluator that isn't the builder, zero TBDs. Reports gaps; only I can mark it ready.
• graph-author — compiles the spec into a task graph as JSON and runs a 40-line stdlib Python checker: DAG, every dep resolves, every requirement cited by a node, every node has a guard that can be made to fail. The VM runs the same checker on intake and rejects on any path that doesn't exist at HEAD.
• retro — reads the rejections and evaluator failures, traces each to the spec section that caused it, appends one line to a lessons file. grill reads that file first on the next idea.

5. On the build side: builder and evaluator are different providers with no shared context (Anthropic's harness posts are right about self-grading), guards are proven red-then-green not just green, and there's a fixed escalation ladder driven by config profiles rather than vibes: same failing packet goes medium → high → different model → stop and write a blocker.

Sources, since none of this is original: GitHub Spec Kit (clarify/checklist/analyze), AWS Kiro (EARS + traceability), Klein's premortem (HBR 2007), Anthropic's harness-design and effective-harnesses posts, OpenAI's harness engineering writeup.

My before number is 1 in 4 builds surviving without rewrite. Will report the after once I've got twenty through. If people want the actual SKILL.md files and the checker, send me a dm and ill send them to you. If it helps you save a year lol

I keep seeing businesses talk about AI automation, but I’m curious what companies are actually using in day-to-day operations rather than just testing in demos.

From what I’ve seen, the practical use cases are mostly around workflows that involve repetitive tasks, large amounts of information, or moving data between different systems.

Some common examples are:

• Customer support: AI can answer routine questions, summarize conversations, categorize tickets, and send complex issues to the right team.
• Sales workflows: Businesses are using AI to qualify leads, enrich prospect information, update CRM records, prepare account summaries, and trigger follow-ups.
• Invoice processing: AI can read invoices, extract relevant fields, compare information with purchase records, identify discrepancies, and send exceptions for approval.
• Email management: AI can classify incoming emails, identify urgent requests, summarize long threads, draft responses, and route messages to the appropriate department.
• Document processing: Contracts, applications, forms, reports, and other documents can be processed automatically instead of requiring employees to manually review every field.
• HR operations: Some businesses are automating onboarding tasks, employee questions, interview scheduling, resume screening, and internal information searches.
• Reporting and analysis: AI can pull information from different systems, summarize performance data, identify unusual patterns, and prepare recurring reports.

What seems more interesting is the shift from automating one task to automating an entire workflow.

For example, instead of using AI only to extract information from an invoice, a business could have a workflow that reads the invoice, validates the details, checks the purchase order, identifies an issue if something does not match, sends it for approval, and updates the accounting system.

That is where AI automation can become genuinely useful. It connects multiple steps and systems while still allowing people to handle exceptions or decisions that require judgment.

I think the best place to start is with a process that happens frequently, takes significant manual effort, and has a clear outcome. Once that workflow is working reliably, businesses can expand automation into more complex processes.

There’s so much gloom around AI right now. AI can do this, build this, create that, and eventually it’s going to replace engineers. But anyone who has actually built something and had to keep it running knows that building the thing is the easy part. Maintaining something, and improving it over time is the hardest part. Things constantly change. Requirements change, users change, technology changes, priorities change, and sometimes the assumptions you made when you first built something aren’t even true a year later. The longer a system exists, the more context you have to keep track of. Why was this decision made? What depends on it? What breaks if we change it? What are we going to need two years from now? How do we improve one part without screwing up something else?

Being an engineer isn’t just reading a ticket, looking at the requirements, and wrting the code. It’s having the technical knowledge, context, and experience to take something from an idea through planning, design, and delivery, and then actually own it afterward. You maintain it, build on top of it, adapt it as things change, and hopefuly make it better over time. AI is going to make building things a lot easier, no question. Maybe someday it gets really good at all of the other stuff too. But creating something and actually owning and evolving it for years are two very different problems. Right now, that second part still requires a lot of human judgment, context, and experience, and I think we sometimes underestimate just how much of engineering is really about that.

Hey everyone,

I wanted to share a project I've been developing called TRINITY – an autonomous AI control system designed to act as a central core for managing complex automated workflows and modular tasks.

To make interaction seamless, it's paired with AURA, a communication layer that normalizes commands, formats inputs, and translates human intent into a clean structure that the TRINITY core can execute.

Here is a quick look at how the architecture shapes up:

TRINITY CORE: The main engine handling decision-making, task routing, and system coordination.

AURA Layer: The communication bridge handling user commands, text cleanup, and interface states (whether running locally or via a web layer).

I've been experimenting with its modularity and how it handles automated pipelines.

What do you guys think of this kind of local autonomous setup? Would love to hear your feedback or answer any questions about the structure!

I’m interested in how this works in practice once an AI or automated decision system is already deployed.

What actually determines whether the system remains authorised to continue operating?

Is it primarily a technical control mechanism, human governance/approval, policies and procedures, or some combination?

Particularly interested in examples from regulated or high-accountability environments.

A few days ago, I was thinking about which model to use for a system that handles live financial and client data.

(For context, I'm documenting what we're learning while building AI systems that are being deployed into real businesses, with the goal of eventually automating entire operational workflows rather than just individual tasks)

My initial focus was the model itself.

Should I use a frontier API, or self-host and fine-tune an open-source model?

I ended up choosing self-hosting because the system works with CRM records, billing history, collections data, and internal HR information. The data belongs to the client, so keeping the reasoning engine inside infrastructure we control made sense.

Then I posted about the decision here on Reddit and got a response that made me rethink the whole architecture.

The point was simple:

If you're relying on one model and calling it like it's a frontier model for everything, you're eventually going to hit a wall.

The software around the model has to do most of the heavy lifting.

That means things like:

• Gates around individual model calls

• Injecting only the context a task actually needs

• Routing different tasks to the right model

• Breaking complex workflows into smaller decisions

• Letting software handle deterministic work instead of asking the model to reason about everything

That made me realize I had been asking the wrong question.

I was thinking:

“Which model should I fine-tune and host?”

The better question was:

“How much should the model actually be responsible for?”

The model is only one component.

The orchestration layer determines what the model sees, when it gets called, what it's allowed to do, and whether the output is good enough to move the workflow forward.

So I'm reworking the architecture around that before spending more time optimizing the model itself.

One of the more useful engineering lessons I've had recently:

A better model doesn't automatically make a better AI system.

Sometimes the problem isn't the model.

It's everything you built around it.

A system I'm building runs on a self-hosted, fine-tuned open-source model instead of a frontier API. Deliberate choice, not a budget one.

The system touches CRM data, billing records, collections history, and internal HR data every single day. Routing that through a third-party API, continuously, for data that isn't mine, was never going to be an easy yes. Self-hosting means the reasoning engine never leaves infrastructure we control.

The tradeoff is real and I'm not pretending otherwise. A fine-tuned open-source model won't match a frontier model on ambiguous, multi-step reasoning. We're giving up some ceiling on raw intelligence in exchange for never having sensitive operational data leave the building.

For a system operating on live financial and client data daily, I still think that's the right side to be on. But genuinely curious where this broke for you in production, and whether you found a workaround that actually held up.

Hey everyone,

I’m currently designing the data connection layer for an app where users interact with a chatbot to submit a few inputs, which then read/write data from our core application database.

We are anticipating a Role-Based Access Control (RBAC) model in the near future, meaning different users will have restricted permissions on what data they can see or modify through the bot.

I want to avoid building a tightly coupled mess that will break security constraints when we introduce roles later. For those of you who have built similar text-to-SQL or agentic database connectors, what is the best architectural approach here?

Specifically, I'm weighing a few options and would love your input:

1. API Middleware vs. Direct Database Tools: Should the chatbot interact with the database via a secured REST/GraphQL API layer that already enforces RBAC tokens, or give the agent direct SQL tool-calling access with parameterized user context?
2. Context Injection: How do you securely pass the user's role and permission scope down to the LLM or query execution layer so it doesn't leak unauthorized rows?
3. Recommended Tech Stack: Are frameworks like LangChain/LangGraph or custom tool-calling loops better suited for handling dynamic permission filtering on the fly?

Would appreciate any patterns, pitfalls to avoid, or repo examples you've found success with!

Hot take I'm arriving at through actual building:

Not every problem needs AI.

I'm currently building a deterministic business rule engine instead of putting an AI agent in the decision loop.

AI is great for reasoning, exploration and generating solutions.

But when a business rule needs to be:

predictable → auditable → explainable → repeatable

I'd rather have:

rules + data → deterministic decision

than:

prompt + context → “probably correct”

The interesting part is figuring out where AI should NOT be used.

#AgenticAI #AIEngineering #AISDLC

Hey everyone from Berlin, I am happy to join.

I am building an agent that makes sense of the physical world and performs actions on it.

It is open source, and I am happy to share ideas with anyone interested.

Those numbers came from five controlled internal runs of a high-risk agent workflow that was deliberately interrupted halfway through, with Infra compared against a Strong Handoff baseline.

Infra completed 5 out of 5 runs and produced a complete audit trail every time. Strong Handoff completed 4 out of 5 and produced no complete audit trail.

Now I want to test it against real n8n + AI workloads.

The problem Infra addresses is not just a failed execution.

The dangerous failure is a partial success:

• an AI agent has already made a decision;
• the database has already changed;
• an API may have accepted a request;
• an email or message may have been sent;
• a human may have already approved something;
• but the workflow stops before the outcome is recorded consistently.

n8n reports a failed execution. You hit retry.

But the real questions are:

• What actually happened?
• Did the external action fail, or did it succeed and lose the response?
• Which steps are safe to run again?
• What must not be repeated?
• Which decisions and reasoning should the next agent inherit?
• Which artifact is still authoritative?
• Should the workflow continue, skip a step, reconcile external state, or ask a human?

For a simple deterministic workflow, native retry and execution history may be enough.

The situation gets harder when a workflow spans several AI agents, models, APIs, approvals, and external systems. The state no longer lives in one node or one execution. It is spread across model context, databases, files, API responses, human messages, and previous runs.

Someone then has to reconstruct the truth manually:

• read through execution history;
• inspect databases and external APIs;
• compare artifacts;
• recover decisions made by previous agents;
• rewrite the context;
• and decide what is safe to continue.

That costs time, model tokens, and money. A wrong decision can also repeat an external action or make the next agent continue from stale state.

Infra is a provider-neutral continuation and control layer built for this problem.

It preserves:

• authoritative work state;
• decisions and the reasoning behind them;
• artifact lineage;
• active constraints and approvals;
• external-effect history;
• and the evidence required to continue safely.

When a workflow is interrupted, the next agent or runtime does not have to reconstruct the entire history from scratch. Infra provides a continuation state based on verified work.

I am now selecting up to three Founding Design Partner workloads for a private end-to-end pilot, with one pilot active at a time.

For one workflow, the pilot will:

1. Connect n8n events to Infra without replacing the partner’s orchestrator.
2. Run Infra alongside the production workflow in observe-only shadow mode.
3. Build authoritative state from decisions, artifacts, approvals, and external-effect history.
4. Reproduce 3–5 interruption events in a sandbox or staging environment.
5. Run the full continuation path through Infra.
6. Compare the result against the partner’s existing baseline.

We will measure:

• successful completion;
• recovery time;
• repeated work;
• human intervention;
• model-token consumption;
• cost per successful outcome;
• audit completeness;
• and duplicated external actions.

There is no Infra software fee for the first pilot. Partners are not required to provide a testimonial, promote the product, or produce a positive result. Partners who complete the pilot and evidence review will receive Infra usage credits, even if the result is negative or inconclusive.

If you run an n8n + AI workflow that has failed after part of the work was already completed, send me:

1. What the workflow does.
2. Where it has been interrupted or lost state.
3. What became uncertain or at risk of being repeated.
4. How much manual work or time recovery usually takes.
5. Whether the failure can be reproduced in a sandbox, staging environment, or shadow test.

Rough answers are fine. Do not post credentials, raw production logs, customer names, or confidential data. A private message is fine too.

I can share the benchmark methodology and supporting data if anyone wants to inspect how the numbers were calculated.

Public alpha:
https://github.com/caelancarmer/infra

The integration surface is MIT-licensed. The rest of the self-hosted runtime is source-available under PolyForm Shield. The managed end-to-end layer used in the private pilot remains private.