voodooEntity

You sir are a legend to me :D i already can tell i will spend to much time in this in the future xD sc 4 ever

When i wrote my own harness, i didn't rely on what other agents do, but rather sat down and considered how i can solve the issues that i have when using other agents. And tbh, for alot of problems there are rather "simple" fixes - each comes with a cost tho. For me it was accepting to run more inference than "standard" agents but in return solving alot of issues those agents have. And to me having a full autonomous agent that i can task and just come back hours later to a solution is much more worth than just an agent that i need to "prompt jokey" the whole day.

I think its important that people don't just look at whats implemented rn, but rather just try out new things , not just "adjust" the existing ones. Thats how we got better progress, not by trying to build the 1000s variant of context compression but rather reconsider how can context be build to not have this issue (simple example).

Well that was one of the reasons why i build my own agent/harness - to have actual full observability of what it is doing and why it is doing what it is doing.

Don't really understand why other agents to give those insights but well found my solution.

Haha thought the exact same

It's not like i didn't consider that step :D but as mentioned in another response the game contains some rather complex configurator etc systems that i already completely baked with the godot system, also a simple map editor that works fine - so im not to motivated to also rewrite them all. Apart from that its a hobby project (one of many) so well maybe i reach that point and go full c++ but for now i dont think i will.

Again combination of multiple points but for some part this is correct.

One side is that i started developing it with godot, and the game has well alot of menu stuff going on (without wanting to go to much into detail but you are to a certain degree able to configure units outside of a match into "blueprint" like system). This whole editor / management etc stuff got quite big and works really well.

Means, when i hit the gdscript limits, i did not want to port all of the existing stuff that already works perfectly fine with godot.

And ye since the c++ only runs math simulations but i still use the godot renderer (which so far seems to work out perfectly fine) i was okay with that mixed solution (for now).

A combination of two factors that are rather specific to myself. One being that even tho its quite some time ago i have a bit of c++ experience, while i never tried to code C#. So when i got the idea to try to run the heavy simulation in an "extension" it was just a language i was a bit familiar with. Maybe C# would have been the "smarter" choice, i just never digged into it yet.

The other reason is that in my well closer circle i got quite some people that code c++ on a daily basis and i don't know (at least i think so) anyone doin C# actively, so i thought if i would get stuck i have people i can easily ask about my c++ problems.

So it wasn't a "i think c++ is better than c#" decision rather a what do i know and what resources i have available easily.

Was playing arround recently building an RTS with godot until i just hit the ceilling of what i could handle with gdscript performance wise.

Than started to move alot of heavy logic to c++ simulation : tedious indeed but the results speak for themself.

Basically allows me to use godot for things like menus dialogues and similar stuff while running the true heavy work in a c++ simulation.

Im working on my own coding agent soon to be released.

While you might think "yey another coding agent" i went down some very different paths than other open source coding agents do right now. Ill not bore you with a ton of detailed breakdowns and rather list the main points that are relevant to understand why/how i build it.

Premise:

-The agent is meant to run against selfhosted environments first like Ollama etc with a focus on non cloud sized models, it should work properly on something like a 27b model already

-The agent with full intention trades execution time vs reasoning and result quality

So what does it do different:

1. The agent, instead of trying to let the model solve a whole task in 3-5 inferences, rather breaks down the "thinking process" in smaller chunks, basically decomposing the task into smaller tasks. While this is not a completely new concept, the agent will break it down to really simple single step variants which even for a smaller model can properly be solved. This involves not just file editings but all points along the way from interpreting user message to planing a task to defining acceptance criteria etc.

2. The agent is build in a way that it, apart from some fixed steps such as detect user intent at the beginning and synthesize response at the end, it will by itself decide what is the next proper step to execute/do based on the context i provide. While doing so the agent also revalidates its current execution and if it spots that, given the information i collected since it planned and started running, the current plan is not detailed enough or is missing out due to something he didnt "know" when he was planing, the agent will dynamicly mutate the coming plan stats, as in restructure/decompose/etc in order to have a properly layed out route to fulfill the task.

3. The agent has a rather complex system of how his context is composed which is combined by things like the chat history, previous step results, a backlog of what "single steps" it has done (updated file x , read range from file y etc) and in that it is strongly reason driven, so it will for most of the things it does also provide a small reason explaination for why it did that. Than the agent also has a working memory that contains facts and decisions it made along execution. There is more but thats just some thingsd to mention. The whole memory system and context is rather complex (tho not complicated). When i release it ill properly break down how all this works in the docs.

4. The agent provides full observability in the ui. At every point of execution you can basically in detail see whats in memory, whats the current composed context, whats the plan and what plan steps depend on what previous steps, you can look at artefacts it build and also you have basically a complete audit log of all single "actions" it has executed and can look into their details.

5. The agent allows to while in an execution send steering messages, meaning the message will be, using relevant current contextual information about its execution, send as inference with a prompt askind the agent to interpret on if its relevant, and how does it impact the current execution/plan. It than can decide either just do alter what it currently does, or even do a plan mutation in order to accomodate the users steering information.

6. The agent within its capabilities has a lot of error correction/self reflection logic. From dynamicly fixing json including a fallback to let LLM fix a response json, upon to if executions fail to much it will itself do a hypothesis on why this is happening, formulate a critique and with that reevaluate if it wants to try the steps again with the additional information, or if it wants to mutate the plan to accomodate the just spotted problems.

Theres quite some more i could list but i guess thats enaugh for now. The big trade off as mentioned earlier is execution time. In comparsion to cloud native agents, which will do giant editings and reasonings in just a hand full of inferences, my agent uses a ton of inferences. The big difference is that this allows (a) the agent to more precisly focus on specific tasks rather than overloading it with to much at once and (b) alot better spot problems/mistakes itself and adjust its execution plan to accomodate those without the user having to reprompt the agent 10 times until something is actually correctly solved.

Apart from the pure coding capability, the very same actions that allow for higher quality reasoning and coding at the same time allow the agent also be a good analysis and discussion partner.

So : what is it than used for if inferences and executions can take very long? Well for me its in terms of coding capabilities a hands off agent. Its meant to be informed once at the beginning with relevant details, and than should be fully capable (as long its in the capabilities for sure) to fulfill the task without the user having to permanently keep an eye open. I want to free time for myself and not change my time from coding to prompting.

Ill wrap it up here and say : the Agents name is "Loa" and i probably will post it on hackernews as soon i got a relatively stable beta to release. Im close to being fine with a beta release but i want to test some more runs before i publish.

Tbh in a time where more and more applications are shipped as vibecoded electron based bloated bug-collections that are slow and take stupid amounts of resources i'd rather have even more TUI's than less.....

No os² feel like this list should have gotten more entries and love before publishing

Funny, i did this myself some months ago - its actually not that tricky to run a llm in your browser. Tho, the problem is that the models fitting in there are well relativly "tiny" in my opinion.

Cool idea tho to make it as accessible (: