I've been around the 'net long enough to remember when Altavista didn't even have it's own domain name, it was altavista.digital.com, this triggered some great memories of my first year or two using the web on the only computer in school with access to it.

It seemed to take them a really long time to get rid of the digital part, probably because marketing thought it was good thing. At least it didn't require you to prepend www.

I think OP is referring to this https://www.thebellrock.co.uk/lunch-buffet which does appear to be a fish-n-chip buffet of sorts (amongst other things) which has been in various tabloid newspapers in the last month or so.

I'm working on something similar (won't link to it as don't want people to think I'm spamming) but if you want to compare notes happy to talk.

I've been working on an integrated deterministic/agent integrated system for a few months now. It basically runs an AI step to build a plan, which biases towards deterministic steps as much as possible but escalates back to AI when it needs to (for AI only capabilities or deterministic failures) so effectively (when I perfect it, I'm about 90% there) it can bounce back and forward as needed with deterministic steps launching AI steps and AI steps launching deterministic steps as needed.

Probably not explaining it very well but I think it's pretty effective at reducing token usage.

I've been building a workflow engine for agent orchestration and the workflows are just data for the engine to execute. While I haven't experimented with it yet, I envision that an LLM would be rather good at generating the workflows based on a description of your needs (and context about how best to utilise the workflow engine).

LLM's are pretty good at reasoning about workflows, its just that when they have to apply them directly, the workflow context gets muddled with your actual tasks context. That's why using an orchestration agent that delegates work to worker agents works so much better.

I still think there's a huge amount of value in having the workflow executed in a deterministic way (as code, or by a workflow engine) because it saves tokens, eliminates any possibility of not following it, and unlocks other cool things, like being able to give each step in the workflow its own focused task-specific context, splitting plans into individual actions and feeding them through a workflow one by one, and having workflow-step specific verification.

But that workflow absolutely CAN be created by an LLM, it just shouldn't be executed by one.

Haven't looked at the app itself but the MCP tool problem is mainly solved now using lazy loading, it's far from perfect but the immediate context window overload problem is gone (in clients that support it anyway).

Now just onto the fact that most MCP tools are just transforming API calls and their functionality and return data structures suck for LLM's....

Nope, at least for ours it limits on export produced (on a technical basis, not a planning permission one). It will deliberately downgrade the energy produced to ensure it doesn’t exceed export limits. You get used to optimising for sunshine for when you run power heavy equipment eg car charging

You always knew when summer had arrived when you could smell burnt brakes!

Saw more than the occasional jackknifed lorry as well on that hill

Very random seeing Porlock on here. I grew up in the Village, although haven’t been back in many years

Have just signed up, was (yet again) looking for a solution like this for monitoring outbound API calls. Look forward to trying it

Exactly that, it was known as the ‘script.ini’ problem, the download directory was changed as well.

It would attempt to send to people as they joined a channel.

More info: http://www.irchelp.org/security/si.html

there was the funny magic string that would make half a channels modems disconnect too.

Ah, yes, I remember that. I think it was because the modems didn't differentiate between the various layers in the transport stream and took anything resembling low-level modem commands to be gospel.