AITimes

Claude wrote a 5-page pitch for my company that read like a case against working with us. So I had my local 27B write the same thing. The gap is the whole story. I asked Claude to write a business document. It wrote a case against working with us. I run Proprioceptive AI. Our work is mechanistic interpretability, internal-state monitoring, targeted model control, behavioral diagnostics, verification, and self-repair. It's a body of technical work — not a single hallucination detector, not one recent benchmark. I'd already talked with a major enterprise prospect. My read of the meeting was that they didn't see a clear use case or strategic alignment, and I thought we'd failed to communicate the fit. The capability was there — it mapped almost line for line onto what they build. So I wanted a short, confident commercial paper for our intermediary to review before we approached them again. Not a research proposal asking them to fund experiments. A deliverable. The objective was simple: explain the problems our technology addresses, connect each problem to a specific capability, describe what we can deliver, and show why working with us creates value. Their document-analysis workflows need answers that reflect the supporting material, including exceptions and qualifications. Their engineers need to diagnose recurring failures and preserve useful behavior across changes. Their agents need to recover from failed actions and verify the work product is actually complete. Their enterprise deployments need control over sensitive data and infrastructure, down to air-gapped operation. Claude did the research well. It found that the prospect had launched its own model, that the model sat inside a named product, and — most useful — that the prospect's own technical report discussed directional model editing, preserving capabilities, and the difficulty of reliably selecting the strongest generated answer. Those were concrete hooks. It had more than enough to explain why we'd be useful. The pitch could have been: here's the workflow, here's the capability we bring, here's the component we integrate, here's how the customer benefits. Instead, Claude produced a five-page document that kept interrupting the commercial case with reasons to hesitate. It told the buyer the technical overlaps were "not proof that our methods improve their model." It listed, up front, that there was no experiment, no commitment, no integration, no deal. It spent space on what our interpretability does not claim to do. It leaned on compatibility constraints. It distinguished the use case from whether their venture fund would invest. Some of those statements are reasonable in isolation. The problem was that they became the document's whole posture. It read like a risk assessment. The most telling part was how it handled our internal development work. It described a development comparison improving from 11/20 to 13/20 completed workflows — then emphasized that runtime went up, that some steps were simulated, and that a configuration change made attribution complicated. It volunteered that a separate recovery test stayed flat at 2/6 and was not promoted. It highlighted another configuration that increased false-completion reports and was also not promoted. That's genuinely useful material for an internal engineering review. As the lead of a short commercial document to a prospective partner, it was a strange choice of emphasis. What I was watching was an assistant that kept reaching for the absolute newest artifacts instead of selecting the most relevant evidence from the company's broader work. It was presenting us as a collection of recent research experiments rather than a company with capabilities to deliver. And none of this was me asking it to make things up. That distinction matters. I wasn't asking it to invent production deployments, fabricate customer results, or promise universal performance. I was asking for basic commercial communication: pick the relevant, truthful material, explain the value, describe the deliverable, and place technical qualifications where they actually help the reader decide. Engineering rigor should strengthen a pitch. Verification, preservation checks, rollback controls, evidence records — those are reasons an enterprise buyer can trust the delivery process. My reaction was honest: "what a terrible pdf lol it's written like a case against working with us." Claude Agreed. It acknowledged it had buried the value under caveats and made the document read like a risk assessment. It rewrote it around the customer workflow, our contribution, the deliverable, and the value. Then the next problem showed up: the writing went generic. It had removed some of the self-defeating material without replacing it with enough real differentiation. The proposal got smoother while still failing to represent the breadth of what we actually do. I said: "you talk about the absolute newest results and items only — you're not selling a research company, man." And: "You sabotaged your own pitch by aggressively highlighting your own worst benchmarks and non-promoted failures, as if looking for a reason to reject yourself. Instead of framing your engineering rigor as an asset, you wrote a brief that actively tries to talk the buyer out of working with you. Enterprise buyers want absolute confidence and a clear path to value, not a list of self-doubt and post-mortem caveats." That was a request for confident, accurate positioning — not a request for guaranteed outcomes. Claude revised again. I asked it to cut the document in half. It produced a two-page version and reported it was roughly 59% shorter. By then we were several rounds in, and I was explaining the same underlying objective for the fourth time. So I had my local 27B model write the paper. The result had a clearer structure and more technical substance. It connected the specific engineering overlap to the proposed engagements and deliverables in a way I found much more convincing. The structure: why the prospect is a relevant fit; evidence presented near the front; distinct engagements for document analysis, model updates, and agent completion; mechanistic diagnostics, targeted control, and selection as separate capabilities; deployment and defensibility; a delivery and acceptance framework; and a commercial path with a concrete next step. My honest assessment is that its overall organization, technical detail, and presentation were substantially better than what I'd been getting after repeated corrections. I uploaded that PDF to Claude and asked it to read it. Then I asked: "you agree your paper sucked compared to this one?" It answered: "Yes. Yours has a stronger structure, clearer technical substance and a more credible connection between our capabilities and their needs. Mine became generic as I shortened it, after initially burying the pitch under caveats. I missed the balance between confidence, specificity and evidence." That's its actual response, and I'm using it accurately. I'll also be straight about what it is and isn't: an assistant agreeing its paper was weaker is part of the story, not independent scientific proof of superiority. Why this matters to me: this was a real business task. The cost wasn't whether a paragraph sounded nice. A poorly framed document can make a capable company look uncertain, immature, or irrelevant. If the buyer sees a research diary instead of a clear commercial proposition, the writing has failed — and the opportunity goes with it. I had already given the objective, corrected the audience, explained the breadth of the work, and asked repeatedly for concrete deliverables. The hosted assistant could acknowledge each correction, explain why I was right, and still not produce the right artifact consistently. The local 27B Qwen on a Hermes Harness gave me something I preferred for the actual job. I want to be clear about the limits, because the point only holds up if I am. This was a real workflow comparison, not a controlled benchmark. I'm not claiming local models win every task, and I'm not claiming that particular local paper was flawless. I'm not even sure what the hosted assistant was running under the hood, and I don't need to be. The point is smaller and, to me, more important: practical usefulness. A model's reputation does not write the document for you. A model that produces an artifact you can actually use can be the better tool — even when it is much smaller than the hosted systems people assume will win. That's what changed for me. I don't need an assistant that can eloquently agree with every correction. I need one that understands the business objective and delivers the paper. Something has seriously changed with Frontier API models. They did not suck this bad 6 months ago.

If you serve on a board of directors and believe your company is burning hundreds of thousands—or millions—of dollars on AI APIs and unnecessary compute, let’s have a conversation. I think your concern may be justified. I will help you show the board exactly where the money is going, what the company actually receives for it, and whether continuing with the same architecture is a responsible fiduciary decision. Too many companies have mistaken access to an AI API for an AI strategy. They are paying repeatedly for models they do not own, sending the same institutional knowledge across an external boundary, retransmitting enormous contexts, absorbing unpredictable price changes, and building critical operations around providers whose models, limits, policies, and product priorities can change at any time. The cost looks small during experimentation. Then the system enters production. Every employee begins using it. Agents make multiple calls. Failed calls retry. Context windows expand. Retrieval systems resend documents. Workflows use expensive models for tasks that smaller models could perform. A single business action may quietly require dozens of model calls. The organization pays for every token, every retry, every repeated instruction, and every piece of context the model must reread. At scale, this can become an enormous recurring expense without creating a corresponding company-owned asset. Meanwhile, local AI has changed dramatically. Open models are improving quickly. Quantization, sparse mixture-of-experts architectures, speculative decoding, optimized inference engines, CPU execution, system-memory inference, and modern agent harnesses have made serious private deployments practical. People are already reporting GLM 5.3 running on CPU-based local systems at roughly 50 tokens per second. That should end the assumption that useful local AI always requires renting access to a hyperscaler’s infrastructure. But cost is only one part of the problem. The privacy is often inadequate. The company’s prompts, customer information, internal research, source material, operational memory, and decision history may repeatedly leave its controlled environment. Even where providers offer strong contractual safeguards, the organization still accepts another dependency and another security boundary. The institutional knowledge is also being built in the wrong place. Years of prompts, corrections, evaluations, workflow design, retrieved documents, agent memory, and employee feedback should become intellectual infrastructure owned by the company. If the organization cannot move that capability away from its provider without rebuilding everything, it has created dependence rather than an asset. Quality is another problem. Sending every task to a famous model does not guarantee that the task is being completed well. Models hallucinate. Agents loop. Tools are called incorrectly. Retrieval supplies irrelevant context. Long prompts bury the real instruction. Large models are used where smaller specialized models would be faster and more reliable. Companies often measure API availability while failing to measure completed-task accuracy, unsupported claims, retry rates, human correction time, latency, or cost per successful outcome. The best modern harnesses can make local models reliable agents by combining: model routing; structured tool access; retrieval; durable memory; constrained permissions; answer verification; uncertainty detection; hidden-state monitoring; specialist adapters; human escalation; and continuous evaluation. The model is only one part of the system. The harness determines what it can do. The memory system determines what it retains. The evaluation layer determines whether the company recognizes failure. The routing system determines whether a task needs a small local model, a larger private model, or an external frontier API. The monitoring layer determines whether the company understands what the system is doing before a bad answer reaches a customer. This does not mean every company should abandon external APIs. It means every external call should earn its cost. A responsible architecture may be entirely local, on-premise, privately hosted, or hybrid. External frontier models can remain available for the narrow tasks where measured performance justifies the added cost and exposure. The rest can run on infrastructure the company owns and controls. A board evaluating its AI strategy should demand clear answers: What is our total AI cost by workflow? What is the cost per successful completed task? How much spending comes from retries, oversized contexts, and unnecessary agent calls? Which tasks demonstrably require a frontier model? Which tasks could run locally without reducing practical quality? What happens to our costs if usage increases tenfold? Where are prompts, memory, customer information, and proprietary research stored? Can we change providers without rebuilding our operating system? Have we benchmarked a local or hybrid architecture using our actual work? Are we accumulating permanent intellectual infrastructure, or paying rent indefinitely? If management cannot answer those questions, the organization does not yet have a serious AI strategy. Proprioceptive AI has spent years conducting independent AI research across model internals, hidden states, interpretability, probes, adapters, hallucination reduction, model evaluation, memory, agent control, and controlled steering. We do more than recommend a different model. We investigate what the system is doing internally, identify where it becomes unreliable, measure failure before it reaches the user, and design practical local or hybrid systems around the organization’s actual requirements. We can help a company determine: which workloads should remain on commercial APIs; which workloads should move locally; which models fit each workflow; where the current system is wasting compute; where hallucinations or unstable answers originate; how private memory and retrieval should be structured; how agents should be constrained and monitored; and how to turn AI spending into infrastructure the company owns. If you believe your company is burning capital on AI without building a durable capability, you may be right. Let’s measure it, put the evidence in front of the board, and determine the responsible path forward. I'll talk to your board or anyone who you think needs to hear this. Book a conversation: calendly.com/logan-proprioce…

We show that a small set of internal coordinates can predict future hidden states—and, more importantly, that intervening on those coordinates measurably changes downstream internal dynamics. In our experiments, 8 internal coordinates predict a 68-dimensional future target, while targeted interventions reduce downstream internal prediction error by 21.68–43.79% across registered cells. The broader idea is simple: If you can predict where a model's internal state is going, can you intervene and change where it goes? These results suggest that the answer may be yes. proprioceptiveai.com/From_In…

What is your AI doing wrong? It works in the demo. It fails in the workflow. Wrong answers. Unreliable agents. Scores you can’t explain. Most teams only look at the output. That’s too late. We treat model behavior as an engineering problem: Observe → Compare → Verify Bring one failure. 30-min intro call is free. Book: calendly.com/logan-proprioce… instantguardrails.com