Specifically:

- Giving agents access to programmable runtime orchestration (Aspire.dev[0]) - Empowering agents to iterate rapidly with runtime mutability (using CSharpRepl[1]) to dynamically modify code at runtime while retaining full application state - Using the GitHub Copilot SDK to build an agentic core with a multi-platform harness, BYOK, any model provider - Testcontainers[2] with automatic transactions to streamline and isolate integration tests - A well-documented, AI-friendly UI framework (Nuxt UI[3]) - Logging and telemetry to give agents insights and visibility into the runtime state of the application

The core setup is used at a series C, post-YC startup to ship fast with AI while maintaining high quality standards (in combination with other tools facilitating code review and context management)

Part 1 (https://chrlschn.dev/blog/2026/08/the-unexpected-ai-stack-cs...) is an intro into a few key parts of this stack.

Part 2 (https://chrlschn.dev/blog/2026/08/the-unexpected-ai-stack-cs...) is focused on walking through the hands on scaffolding.

Part 3 (https://chrlschn.dev/blog/2026/08/the-unexpected-ai-stack-cs...) covers wiring GitHub Copilot SDK as an agent runtime and incorporating CSharpRepl to allow agents to dynamically work with the runtime DI container

Part 4 (https://chrlschn.dev/blog/2026/08/the-unexpected-ai-stack-cs...) wires up the test harness using Testcontainers to give agents isolated test environments

Part 5 (https://chrlschn.dev/blog/2026/08/the-unexpected-ai-stack-cs...) wires up logging and telemetry to give agents visibility into runtime state and I start to build the prototype application now that the foundations are ready.

---

The project repo is here: https://github.com/zeeq-ai/zeeq-tmpl (be sure to check the branches; main is currently the base code only)

I encourage working through the posts since the goal is to underscore the platform level decision making process and assembly of the foundational core.

[0] https://aspire.dev/

[1] https://fuqua.io/CSharpRepl/

[2] https://testcontainers.com/

[3] https://ui.nuxt.com/

Comments URL: https://news.ycombinator.com/item?id=49332692

Points: 2

# Comments: 1

Truth is that useful dev workflows and tooling probably coalesces in a tight band. There's really no point in re-inventing the wheel over and over again at this level (the raw tooling).

Open source repo (.NET 10 + C# + Postgres): https://github.com/zeeq-ai/zeeq-app

Docs and more info: https://zeeq.ai

Comments URL: https://news.ycombinator.com/item?id=49221508

Points: 3

# Comments: 0

MCP over streamable HTTP is just JSON RPC payload over HTTP.

The internal interface for the ChatGPT app and Coded are all MCP based (stdio on local).

All enterprise AI rollout is eventually going to converge on MCP as a key piece of that infra because it can mask credentials behind one gateway that's easier to control and more secure.

Same with any of the off the shelf harnesses.

Go build something useful instead of tweaking the minutiae of the harness.

Wrote about this back in March: https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/

MCP is going to be a foundational piece of enterprise agent infra.

Doesn't make sense to me, but to each their own.

Given functionally unlimited access to tokens with frontier models, there is really no "force you to keep busy"; it should just bake overnight. We're talking about a rather simple and well-defined specification; not something novel and complex.

(I want Codex to implement MCP Prompts because then we have one central way to ship skills from a server).

The fact that neither platform can implement a protocol given what is functionally infinite frontier model tokens really says a lot. I do not care what kind of random project some influencer can ship with a swarm of 1000 agents. If you cannot make the basics work, it is a farce.

Sweetango and Pink Lady are probably what I would consider balanced sweet and tart.

    > And you cannot keep doing high concurrent DROP TABLEs to run your large scale CRUD app

    df.wait_for_schedule()

For this[0]:

    -- Wait for human signal (5 minute timeout)
    ~> (df.wait_for_signal('approval', 300) |=> 'sig')

    ~> df.if(
        $$SELECT NOT ($sig::jsonb->>'timed_out')::boolean
            AND ($sig::jsonb->'data'->>'approved')::boolean$$,

Also not immediately clear: how to handle errors/exceptions?

[0] https://github.com/microsoft/pg_durable/blob/main/examples/i...

Totally worth the listen.

    > We are shipping more features

If you increase your spend -> ship more features -> no correlated increase in revenue, that's just burning money.

If a team of 10 spends 1 extra headcount ($180k/year) and ships features with no corresponding growth in revenue, what does that mean?

There was probably a reason it was on the backlog (because it didn't really have value).

Normal people have to produce something of value from that spend. So starting 100 agents and then waking up to something cool but useless just means you spent a few thousand dollars and created nothing of value............

Uber engineers do not define their revenue stream; the product leadership team does.

$1500/mo of AI spend by engineers does not equate to revenue. They need to figure out revenue first before zeroing in on AI spend.