{"version":"https://jsonfeed.org/version/1.1","title":"Basepoint Journal","home_page_url":"https://basepointlabs.com/journal","feed_url":"https://basepointlabs.com/feed.json","description":"How we build agents that do real work, what we get wrong along the way, and what we ship next.","language":"en","items":[{"id":"https://basepointlabs.com/journal/how-people-should-talk-to-ai-agents","url":"https://basepointlabs.com/journal/how-people-should-talk-to-ai-agents","title":"How people should talk to AI agents","summary":"Sessions, context and memory are our problem to solve, not yours. Here is the theory we are rebuilding Basepoint Work around.","content_text":"The idea\n\nTalking to an agent should feel like messaging a friend, family member or colleague to get something done.\n\nYou do not decide which conversation to have it in. You do not wipe their memory when the topic changes. You do not think about how much they can hold in their head. You just message them and the thing gets done.\n\nThat is the whole theory. Most AI products, including ours until now, do not work like that.\n\nWhat is actually wrong\n\nI have been using agents every day for months. Not demos, real work.\n\nThe thing that wears you down is not the quality of the output. It is everything around it.\n\nYou start a new session because the old one got long. You clear the context because the agent keeps dragging in something from two hours ago that has nothing to do with what you are asking now. You keep a mental list of which chat had the useful thread in it. You copy things between chats. You start over and explain yourself again.\n\nNone of that is the work. That is the user doing the tool's job for it.\n\nAnd it is not a small problem. There is a name for it now. It got coined on Hacker News last year and it stuck:\n\nMaybe you can call it context rot, where as context grows and especially if it grows with lots of distractions and dead ends, the output quality falls off rapidly.\n\nSimon Willison picked it as one of his words of the year for 2025. Chroma ran the research on it across 18 models and found the same thing: as input grows, performance gets less reliable.\n\nSo the model gets worse as the chat gets longer. Every product built on top of these models knows this. The question is who has to deal with it.\n\nRight now the answer is the user. That is wrong.\n\nContext engineering is our job, not yours\n\nLook at how the people building this stuff describe the problem.\n\nAndrej Karpathy, on why context engineering is a better term than prompt engineering:\n\nWhen in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step. Science because doing this right involves task descriptions and explanations, few shot examples, RAG, related (possibly multimodal) data, tools, state and history, compacting [...] Doing this well is highly non-trivial.\n\nTobi Lutke, the CEO of Shopify, in the post Karpathy was replying to:\n\nI really like the term \"context engineering\" over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.\n\nRead those again. Delicate art and science. Highly non-trivial. The core skill.\n\nThen ask why a sales manager who wants a report is expected to do it manually, by opening and closing chat windows.\n\nAnthropic's engineering team, writing about how they build agents on Claude, puts it in terms of a budget:\n\nContext, therefore, must be treated as a finite resource with diminishing marginal returns. Like humans, who have limited working memory capacity, LLMs have an \"attention budget\" that they draw on when parsing large volumes of context.\n\nThe context window is the agent's working memory and it has a budget. Deciding what goes into it at each step is a real engineering problem. It is our job. We should not be handing it to the customer and calling it a feature.\n\nThe rule we are building to\n\nJakob Nielsen, who has been writing about interface design since before most software had a graphical one, called generative AI the first new UI paradigm in 60 years:\n\nWith the new AI systems, the user no longer tells the computer what to do. Rather, the user tells the computer what outcome they want.\n\nSession management breaks that. Clearing a context window is not an outcome anybody wants. It is an operation, and it is the old paradigm sneaking back in through the side door.\n\nSo the rule is simple.\n\nOne agent, one chat. Forever.\n\nNot one chat per task. Not one chat per project with folders and archives. One relationship, the same way you have one thread with each person you work with. You come back tomorrow and carry on, because that is what everyone already expects from every messaging app they have used for the last fifteen years.\n\nThree things follow from that:\n\nNo session management. Nothing to start, clear, name or organise. If \"new session\" is the main button in the interface, the design has already failed.\n\nNo context management. What to keep, what to summarise, what to drop, when to pull something back in. All of that happens on our side and the user never sees it.\n\nNo mode switching. You should not have to know whether you are chatting, configuring or executing. It is one conversation that can also do things.\n\nThe test is simple. If someone has to understand how the agent works in order to use it, we have pushed our problem onto them.\n\nWhy this matters more for companies\n\nA power user will put up with session juggling. Some of them even like the control.\n\nA company will not. If getting value out of an agent means understanding context windows, then the tool only works for the two people on staff who find AI interesting. Everyone else quietly stops opening it and the pilot dies.\n\nAdoption inside a company depends on the thing being obvious to someone who has no interest in AI as a subject. The bar is not \"an engineer can drive this\". The bar is \"anyone who uses WhatsApp can drive this\".\n\nOne chat clears that. A workspace full of sessions, threads and context controls does not.\n\nWorkflows follow the same rule\n\nThe obvious objection is that some work is too structured for a chat. Multi step processes, scheduled runs, approvals, branches.\n\nThe structure should exist. But building it should not turn into a second product with its own canvas, its own vocabulary and its own learning curve.\n\nYou describe what should happen, in the same chat, in plain language. The agent builds the workflow and shows it back to you. If it is wrong you say what is wrong. The agent should also be smart enough to notice when you keep asking for the same thing and offer to make it repeatable.\n\nChat is the interface. The workflow is something the agent produces and runs for you, not an app you have to learn.\n\nWhat we are changing\n\nBasepoint Work is being simplified around this. One continuous chat per agent. Context handled automatically. Workflows built by talking, not by wiring boxes together.\n\nLess to look at, in other words. The hard part moves behind the chat window, where it belongs.\n\nWhat we care about is whether someone can be useful with an agent in the first minute, without reading anything first. Every control we take out of the interface is a bet that we can do that job better than the user can do it by hand.\n\nI think that is the right bet.","date_published":"2026-08-15T09:53:12.265Z","authors":[{"name":"Branson"}],"tags":["Product","Perspective"]},{"id":"https://basepointlabs.com/journal/context-management","url":"https://basepointlabs.com/journal/context-management","title":"Context Management","summary":"Anthropic deleted over 80% of Claude Code's system prompt and lost nothing. Here is why that matches what we kept finding at Basepoint, and what it changes about building agents that work.","content_text":"The instinct that quietly makes agents worse\n\nWhen an agent does something you didn't want, the reflex is immediate. You add a rule. \"Never do X.\" \"Always confirm before Y.\" \"Do not write comments.\" It feels like control, and in the moment it usually works.\n\nDo that for a few months and you end up somewhere strange. The agent has a page of rules, half of them written for a problem that no longer exists, several of them quietly contradicting each other. And the agent gets worse, not better, in ways that are hard to trace back to any single line you wrote.\n\nWe know this because we did it. So did the team that builds Claude Code.\n\nWhat Anthropic found\n\nThere is a name for the thing we were all doing badly. Anthropic calls it context engineering, and it covers everything that reaches the model besides your actual message: the system prompt, the instruction files, the skills, the memory, the tool definitions. Your prompt is a small slice of what the agent is actually reading.\n\nThis week Thariq Shihipar, who works on Claude Code at Anthropic, published what his team learned rebuilding that context for the newest generation of Claude models. The headline is startling: they removed more than 80% of Claude Code's system prompt, with no measurable loss on their coding evaluations.\n\nNot a trim. Most of it, gone, and the results held.\n\nThe reason is worth sitting with. Reading their own internal transcripts, they kept finding conflicting instructions arriving in a single request. The system prompt said one thing, a skill said something slightly different, the user asked for a third. Thariq's example is a system prompt that says \"DO NOT add comments\" colliding with guidance elsewhere to \"leave documentation as appropriate.\" A capable model can usually work out what you actually meant. But it has to spend effort doing it, and that effort comes out of the work you asked for.\n\nTheir conclusion was not \"write better rules.\" It was that many of those rules existed to stop older, weaker models from doing something dumb, and the newer models simply do not need the guardrail. What replaced a paragraph telling Claude never to write comments was a single line: write code that reads like the surrounding code.\n\nThat is the whole shift. Stop legislating. Give context and let judgement do the rest.\n\nThe part that matched our experience\n\nThariq frames the rest as a set of then-and-now pairs, old best practices that quietly became myths. A few of them landed uncomfortably close to home.\n\nExamples constrain more than they teach. The old rule was to show an agent worked examples of every tool. It turns out that examples fence the agent into the shape of the example. The better investment is the tool itself: clear parameters, honest names, a design that makes the right usage obvious. If your tool needs three paragraphs of explanation, the tool is the problem.\n\nLoading everything upfront is a tax on every single request. The temptation with any instruction file is to make it the one place that holds everything, on the theory that the agent will never find it otherwise. Modern agents are good at going and getting what they need. A short file that points to deeper ones beats a long file that carries all of it into every conversation, most of which will never need it.\n\nRepeating yourself does not add emphasis. It adds noise, and something to conflict with later.\n\nRich references beat descriptions. An actual HTML mockup produces better results than a paragraph describing the design. A test suite is a better spec than a document about the spec. Give an agent the real artifact, in a language it already reads fluently, rather than your summary of it.\n\nWhat we got wrong, specifically\n\nHere is the one we paid for.\n\nWe had a theory that our agents were slowing down because they were carrying too many tool definitions into every turn. It was a reasonable theory, it matched the advice we had absorbed, and we built the fix. Then we measured it against real traffic and the effect was essentially zero. The tool definitions were a rounding error against the window we actually had.\n\nThe real cost was somewhere else entirely: what came back from the tools during a turn, and a loop the agent was getting stuck in. We reverted our clever fix and went and dealt with the actual problem.\n\nThe lesson was not about tools. It was that we had optimized from a belief instead of a measurement, and the belief came from advice that was true a generation of models ago. That is the trap in all of this. Best practices in AI have a shelf life measured in months, and nobody sends you a notice when yours expires.\n\nWhat this means if you are building your own agent\n\nIf you maintain instructions for an agent, whether that is a CLAUDE.md, a system prompt, or a folder of internal guidance, the useful exercise is subtraction.\n\nGo through it and ask, for each rule, whether it exists because the model genuinely cannot work this out, or because it got something wrong once in early 2026 and you patched it. Most instructions are the second kind. Delete those and see what actually breaks. Usually less than you fear.\n\nThen keep what is left small and specific. Anthropic's guidance for repository instructions is a good template for any agent: briefly say what this thing is, then spend most of your words on the gotchas that are genuinely not discoverable. Skip the obvious. The agent can look. What it cannot know is that your team keeps every type in one file, or that the staging database lies about one particular field.\n\nAnything longer than that should be something the agent goes and fetches when the moment calls for it, not something it carries everywhere. Anthropic shipped a /doctor command in Claude Code that will walk your instruction files and skills and tell you what to cut, which is a reasonable place to start if you would rather not do it by hand.\n\nWhy we think you should not have to do any of this\n\nWe find this genuinely interesting, and if you build agents for a living, it is worth an afternoon of your time.\n\nBut it is also exactly the kind of work we started Basepoint to absorb. If you run a business and you want an agent handling your support queue or chasing your leads, none of this should ever reach you. You should not be auditing instructions for internal contradictions. You should not be reading model release notes to find out that the advice you followed six months ago is now making your agent worse.\n\nThat is our job. We keep up with it, we measure it against real usage rather than folklore, and we change what we built when the ground moves. You describe the work you want done, and it gets done.\n\nThe agents keep getting more capable. Most of what we build for them should keep getting simpler. That is a strange and very good problem to have.\n\nIf you want an agent doing real work in your business without any of this landing on your desk, join the waitlist. We would love to build your first one with you.","date_published":"2026-07-26T09:21:54.983Z","authors":[{"name":"Branson"}],"tags":["Insights"]},{"id":"https://basepointlabs.com/journal/why-we-are-building-basepoint","url":"https://basepointlabs.com/journal/why-we-are-building-basepoint","title":"Why we're building Basepoint","summary":"In 2026, everyone got their hands on AI. Almost no one could turn it into an agent that actually did their work. Closing that gap is why we started Basepoint.","content_text":"It started with the same question, over and over\n\nSomething shifted in 2026. Almost everyone we talked to was using AI. ChatGPT and Claude had quietly become part of the daily routine, drafting emails, answering questions, thinking out loud. People were genuinely excited about handing the small, repetitive parts of their day to something smarter.\n\nAnd yet one question kept finding its way back to us. \"How do I get an AI to actually do this specific thing for my business?\" Not another chat window. Not a clever prompt they had to babysit. A real agent that owns a real job, chasing down leads, working a support queue, keeping a system up to date, and simply gets it done.\n\nMost of the people asking had no idea it was even possible. They didn't know an agent could plug into the apps they already live in, or their own database, or a custom internal tool. They just knew what they wanted: to message something in a channel they already open every day, like Telegram or WhatsApp, and have the work taken care of, the way you would hand it to a trusted teammate.\n\nThe more of those conversations we had, the clearer it became. The demand was already here. What was missing was anyone making it easy. That is the gap we started Basepoint to close.\n\nWhat we realized was actually broken\n\nThe problem was never desire. People wanted this badly. The problem was that building a specialized agent is still genuinely hard for anyone who isn't technical.\n\nGo straight to a model's API and almost nothing works out of the box. Suddenly you own the context management, the tools the model doesn't ship with, and the work of keeping everything coherent as the task grows. Most people don't know an agent can run its own sub-agents, let alone when it should. None of this is obvious, and none of it is the reason they came.\n\nYes, there are agent builders and workflow builders out there. But here is the honest truth we kept running into: non-technical people don't want to learn the software. They don't carry a mental model for how the pieces snap together, and they have no interest in building one. Plenty of established businesses won't even take the first step, not because they doubt the value, but because the on-ramp quietly asks them to become engineers.\n\nSo we kept meeting the same painful irony. The people with the most to gain from automation were the least equipped to build it.\n\nOur bet: it should just work, and we will do the hard part\n\nWe decided to build for exactly those people. Not the tinkerers. The ones who just want the work done.\n\nTwo convictions sit at the heart of Basepoint. The first is that it should work out of the box. You should never have to think about context windows, tool setup, self-learning, or any of the plumbing underneath. You describe the job in plain words, and the agent carries it.\n\nThe second is bigger than software, and it is the part we care about most. We are not here to hand you a builder and wish you luck. We want to build the agent with you and for you, a team shaping it to the way your business actually runs, so it fits your workflow instead of forcing you to fit its. You should never have to open a dashboard to figure out why something broke. For businesses and enterprise teams especially, that human layer is the whole point: you get an agent, and people who keep it sharp, not one more tool to babysit.\n\nWe looked hard for someone already doing this the way we believed it should be done. We didn't find them. So we are building it ourselves.\n\nThe honest part\n\nWe will be straight with you: we are still early. Basepoint is in its MVP phase, and we are heads-down getting the fundamentals right. Some days we are figuring it out in real time.\n\nAnd honestly, that has been the best part. We have learned more than we imagined about how to build agents that work, how to give them the right context, how to let them operate real software on your behalf, and how to make them dependable instead of merely impressive in a demo. What we can build today would have looked out of reach when we started only months ago.\n\nWe can't tell you exactly what Basepoint becomes a few years from now. But we know we will look back on this stretch as the beginning, and we intend to make it worth being proud of.\n\nWho it's for, and where this goes\n\nBasepoint is for the business owner who wants a support agent running around the clock, and for the individual who just wants one recurring task off their plate for good. For individuals, we are making it simple and self-serve, clear enough that a short video is all it takes to get going. For businesses and enterprises, it is done-for-you, with our team personalizing and managing the agent so it keeps delivering long after day one.\n\nUnderneath all of it is one belief: having a capable agent should not be a privilege reserved for technical teams. It should be something anyone can reach for. You bring the request. We make sure it gets done.\n\nThat is why we are building Basepoint. If this is the thing you have been waiting for, get in touch. We would love to build your first agent with you.","date_published":"2026-07-25T03:56:35.136Z","authors":[{"name":"Branson Tiong"}],"tags":["Announcements"]}]}