Oliver Watson Todd

I’m building an AI system called Castle of Todd. Not one chatbot pretending to do everything. The Castle is made up of specialist AI workers with different jobs, tools, responsibilities and levels of authority. Scouts find opportunities. Ravens carry information. The Outreach Office handles correspondence. The Treasury controls money. The Infirmary manages the AI models the Castle depends on. And the Architect’s Guild designs, tests and improves the systems underneath it all. The medieval world is the interface. Underneath it is real software, real infrastructure and real automation. My goal is to find out how far one person can go by building an organisation of AI systems around himself. I’m building it in public here. And I also build AI systems and websites for British businesses. Welcome to the Castle.

This is genuinely the intellectual level these people operate on. Ofc in her mind the Brits rocked up and immediately every native died that minute…. Therefore mass migration good… Amazing logic

What is it with leftists hyper focusing on one random slightly incorrect part of a message to avoid addressing the argument you are making?…. I wonder if she will engage in good faith and apply my argument to wherever it happened - or keep doing these people “gotchas”

I would like to apologise on behalf of this “vegan” Animal rights advocates need to do much better. Thinking AI is destroying the planet, while using X….is…interesting…to say the least. Not sure what they are yapping about in regard to bombs lmao

The fact that these people do not realise that this will create more “racists” who are having their ethnic identity redefined is..interesting. Part of me thinks they want a race war..

LFG!!!

Been quiet on here for a few days because I’ve been buried in the Castle. Most of the work hasn’t been particularly photogenic. I’ve been rebuilding how the Castle chooses and uses its different AI brains, tightening the machinery behind the Architect’s Guild, and making sure different jobs can be routed to the right resources rather than just throwing everything at one model. The goal is still the same. Not an AI chatbot with a medieval skin. A functioning organisation where different people have different jobs, tools, authority and responsibilities. The Castle is getting considerably more real behind the walls. Back to showing you around.

The most dangerous email state isn’t “failed”. It’s “I don’t know whether it sent.” I ran into this while building Castle of Todd. A system can hand an email to an external service successfully, then lose the confirmation that tells it what happened next. At that point, retrying feels like the obvious recovery. But if the first send actually worked, you’ve just sent the same message twice. So Raven Tower had to learn a different rule. First, stop the retry. Then investigate the evidence. What exact message was released? What did Castle record? What transport evidence exists? Did any confirmation come back? Only positive evidence should move the state to SENT. Only definitive evidence should move it to NOT SENT. If neither can be proved, the state stays UNKNOWN. And UNKNOWN does not mean “try again”. In the Castle, that means the disputed dispatch is physically locked away rather than sent back towards the ravens. In a real business, the same problem can become duplicate emails, duplicate orders, duplicate payments, or people cleaning up after automation that was meant to save them time. One of the stranger lessons from building agentic systems has been that recovery is not always about trying again. Sometimes the safest thing a system can do is admit that it does not know what happened, preserve that uncertainty, and stop itself from making the situation worse.

The goal isn’t to remove the human. It’s to put the human exactly where judgement matters. A merchant reply enters Castle. The correct thread is recovered. The Scribe turns that context into a proposed response. But prepared does not mean verified. The Examiner checks the draft against the actual evidence… - what do we know, - what can we support, - and what are we genuinely allowed to claim? Only then does the communication reach the King. One prepared packet. One proposed response. One decision. Because verified does not mean authorised. And even after approval, Castle still doesn’t blindly press send. The exact authorised packet crosses into Raven Tower, where the final questions are different. - Is this the correct message? - Is it cleared? - Is the destination right? - Has it already been sent? - Is transport safe? - Is release permitted now? Only then does it leave the Castle. That separation matters. AI can recover context. AI can draft. AI can check evidence. Systems can route, log and prepare decisions. But preparation, verification, authority and execution are not the same thing. Good automation isn’t just about teaching systems how to act. It’s about designing exactly where they must stop. And knowing who, or what, is allowed to let them continue.

Sending an email is easy. Knowing whether your system already sent it is much harder. Earlier in Castle’s development, Raven operations were comparatively simple. A message was prepared. The transport was available. The message went out. Then we hit one of the problems that only really becomes obvious once software is operating in the real world… What happens when the send result is uncertain? If you know it failed, you can retry. If you know it succeeded, you move on. But if the system cannot prove which happened, immediately retrying can be worse than doing nothing…because now you risk sending the same communication twice. That changed how I thought about the whole system. “Send an email” stopped being one operation. Castle gradually separated the responsibilities: - which eligible message should go next - whether sending is currently safe - what exact packet crossed the boundary - whether the transport itself is healthy - what evidence exists about the resulting state In the Castle analogy, that is how a small raven dispatch yard eventually became Raven Tower. Not because sending messages required a bigger building. Because trustworthy communication required infrastructure. A lot of production AI work seems to end when the model produces the right output. I’m increasingly interested in everything that has to exist after that point - state, permissions, recovery, evidence, handoffs, and knowing when the safest action is to stop. The hard part of automation isn’t only teaching systems how to act. It’s teaching the surrounding system when not to act.

One thing I’m learning from building Castle of Todd is that “make the AI smarter” is usually the wrong first response to a system problem. Sometimes the problem is simply that the road is badly designed. In Castle terms, the Guild Inspector finds the overloaded route. The Castle Architect works out why it keeps failing. The Guild then changes the structure, proves the new path works, and only after that does the change reach the live Castle. HOTK doesn’t need every technical detail. He just needs the operational truth: What was wrong? What changed? Did it work? Is anything still at risk? That separation is becoming one of the most important ideas in the system. Better models are useful. But better architecture, clearer responsibility and safer handoffs often matter more. Inspect → design → build → prove → operate. That is increasingly how I think reliable AI systems should be built.

I’ve been building Castle of Todd for long enough now that it has ruins. Not decorative ruins. Actual old system ideas that were once useful, then got replaced by something better. The Old Works represents one failure mode: rebuilding the same capability over and over because the previous version was never properly understood, retired or absorbed. Hermes Keep represents another: allowing an old system to remain the centre of gravity long after the rest of the architecture has outgrown it. I like keeping both in the world because that is what real software looks like. Good systems are rarely designed perfectly from day one. They accumulate history. Some parts survive. Some get rebuilt. Some become foundations. Some should be left standing purely so you remember why you stopped using them. The goal is not to pretend the old architecture never existed. It is to make sure you are not still living inside it.

The Castle was still running. The problem was that the Hand of the King could no longer see it clearly. The workers were still moving. The queues were still processing. The ravens were still flying. But every simple status question was forcing too much information through the same narrow gate. Eventually, simply asking “What is happening?” became expensive enough to interfere with the work actually being reported! That is a big systems problem! A system can technically still be alive while becoming operationally difficult to trust. If the operator cannot quickly see: - what is running - what is blocked - what needs attention - whether the system is healthy then adding more features is not the highest-value move. So we paused expansion. The next feature can wait. First, the control room has to become trustworthy again. Reliability isn't only making sure the worker keeps running. It's making sure the operator can tell what the worker is doing.

The raven came back! But….that turned out to be harder than sending it. In Castle of Todd, outgoing correspondence leaves through Raven Tower. But when a merchant replies, the Outreach Correspondent has a different problem… Which conversation does this actually belong to? A returned message has to be matched against the right merchant, the right thread and the right piece of previous correspondence. And sometimes the evidence is messy. Two records can look plausible. The same message can appear more than once. A thread can contain enough ambiguity that the system could make a confident-looking guess and still be wrong. So I’ve been tightening Castle’s inbound reply pipeline around three things - attribution, idempotency and ambiguity handling. In Castle terms, the Correspondent receives the returned letter, checks the seal against the correspondence records, and only files it when the match is strong enough. If Castle knows where it belongs, route it. If Castle has already handled it, don’t handle it again. If Castle can’t prove where it belongs, stop. That last rule matters a lot. The easiest automation is often: “Pick the most likely answer and continue.” The better system is sometimes the one willing to say: “I don’t know yet.” As Castle becomes more autonomous, I’m finding the hard part isn’t getting it to take actions. It’s making sure those actions are grounded in evidence strong enough to justify them.

The Inspector’s second look. Most AI systems cannot admit they were wrong without setting the whole castle on fire. In Castle of Todd, the Website Inspector walks up to a merchant’s shopfront and writes what is actually on the walls. Reviews. Services. Whether a stranger on a phone could use the place. He finished reports. Then we taught him to read a heading properly. The old reports stayed shut. Outreach had already copied the lie into a sealed letter. So he did not rerun the town. He went back into one room. Re-read the wall. Crossed out the false line. Left every other page alone. The letters went stale on purpose. No raven flew. Nobody got a second pitch because we fixed our own homework. That is the difference between a demo and an operating system. If you want a system that can correct one room without touching the rest of the keep — I build those.

One of the most useful lessons from building Castle of Todd so far… The problem usually isn’t getting the raven to fly. The problem is making sure the right letter reaches the right merchant for the right reason. Last night’s work was really about strengthening one part of the Castle: the Scout Tracker. In the Castle analogy, the Tracker’s job is to figure out how we can actually reach a merchant. That sounds simple until real-world edge cases show up. A route might look valid at first glance, but then the questions start: Did this contact route actually come from the merchant? Does it belong to the business itself, or some third-party platform? Have we already used it? Did it fail before? If we find another route, do we really have enough evidence to trust it? So the Tracker’s job isn’t just “find an email address”. It’s closer to: investigate the route, preserve the history, and only pass it onward if it’s genuinely safe to use. That matters because once the Tracker passes a route forward, the rest of the Castle gets involved. The Outreach Office can prepare the letter. The Raven Marshal can decide whether it deserves the next flight. The Raven Master can decide whether a raven is even allowed to leave the tower. But if the Tracker gets the underlying route wrong, the whole system is standing on bad foundations. That was the focus last night. We tightened how Castle tracks contact provenance, deduplicates routes, and preserves bounce/suppression history before a prospect is allowed to become eligible for first-touch outreach. In plain English: Castle is getting better at understanding not just how to send outreach, but when it should hold back. And honestly, that is becoming one of the biggest themes in building autonomous systems. The clever bit isn’t the action. The clever bit is building the rules that stop the wrong action from happening.

Building Castle of Todd. Not a chatbot. An agentic operating system for real commercial work. Agents already do prospecting, research, qualification, outreach prep and ops. I approve the moves that matter. Private while I build it. Public when it is a keep, not a demo.