I've had great success with the OpenAI agents SDK [0]. This way I've been able to build the sandbox + slack + knowledge-bank integrations independently and be very strict with what I expose to OpenAI.

Looking at the Agents API, it seems like it offers similar capabilities, but reduces the need for hosting? So I get it from a business standpoint, but hosting a python service is very easy now a days, so I don't see the point as a consumer.

[0]: https://openai.github.io/openai-agents-python/

Why not just build this yourself, you literally have AI, why wall yourself into an OpenAI garden. These sandboxed environments are trivial to build.

I found that trying to keep up with their API updates and changes is more trouble than its worth, even with AI. The agents would need to reverse engineer from the OpenAI SDK source anyways, so why not cut the middleman?

If I wanted something portable for multiple providers, I would of course not use the OpenAI SDK at all. It's a conscious choice to go with OpenAI (in this design), it fits for my company at the moment.

I suspect I would get greater value by simply duct-taping two iPhones together into a fold.

The two batteries inside the Duo will allow longer usage.

from the Duo page:

- Up to 31 hours video playback when using the inner display

- Up to 44 hours video playback when using the outer display

You can run one iphone at a time and lap the duo. 64gb iphone SE is going for $140 at best buy right now. I could tape up 10 of them into a jacobs ladder then I'd have 640gb of storage and maybe 10x the battery life of the duo, and money to spare for future expansion iphones.

You could tape 10 Ford Fiestas together but it doesn't mean it laps a Mustang it means you were fine with what the Fiesta could do which, honestly, most people probably (very reasonably) are.

If apple wasn't so scared of letting people get out of the walled garden, I'd be able to do the equivalent of taking those 10 ford fiesta engines and rigging them into a single 40 cylinder monster.

I was a bit disappointed in these numbers because, despite having two batteries and the outer display being smaller, the Duo still has 1 less hour of video playback on the outer display than the iPhone 18 Pro Max.

A bit narrow definition of a "cloud", no..? More like a microservice server on rails

Bits missing from cloud being global CDN (selfhosted), routing, regional sharding, etc.

When writing agentic apps (apps which embed an agent for semantic work), exposing the same tools which are injected into the agents as an MCP allows for practically the same functionality to be debugged and run in a normal agentic harness.

Good for both development and cost reduction, as the agentic harnesses often allow for much greater amount of token usage per subscription, as opposed to API key which always is per volume.

They ensure the company is funded.

This! They sell the company and vision to potential investors

Good luck finding investments by going to events in socal

I am working on a very similar mcp server which allows agents to communicate and share notes without race conditions, using git and s3 as the driver [0]. Funny how "inventions" like these pop up independently.

[0]: slivingdoc.dev

looks very similar to markbase.cloud

I've found that keeping very healthy test coverage solves issues like this. LLMs are very good at validating their own implementations with TDD.

With unit tests you gotta be careful though, oftentimes LLMs skip implementations with mockups that just say "not implemented yet" or similar and then the unit tests become pointless because they start to only test internal structures for being set / not default values.

For me it helped a lot to try to make containerized end-to-end tests and a custom TestMain for this, where I am using podman to run the integration tests. This way the end-to-end tests are forced to be on network level, and you can test protocol and API quirks much easier with LLMs.

Also, never forget to write a bootstrapping docs/ folder so that you don't have to re-explain these things all the time.

+1, I like to test in a similar way. For example if I'm making a CLI, the test will spawn the CLI for each test-case, instead of invoking the code directly. This provides a more realistic flow, and makes it clear which user journeys one is supporting.

Faking responses I often do with environment variables, like:

  ts := httptest.NewServer(...)
  cmd := exec.Command(...)
  cmd.Env = append(os.Environ(), fmt.Sprintf("MYCLI_PROD_ADDR=%s", ts.URL))

Of course, it's better still to go down this turtle stack (e.g. by spawning a local instance of your backend server instead of some faked handlers), but that adds more cost. I find the trade-off OK here.

I actually had to use a similar hack there due to the limitation that go test compilates cannot spawn themselves where I needed to have an environment variable with the actual binary prebuilt before the tests run. Took me a while to understand that TestMain doesn't cover that use case...

On Linux, "self" is /proc/self/exe. In general, I've seen people use `os.Args[0]`. But on checking again, I see there's even `os.Executable()` (https://pkg.go.dev/os#Executable) for this purpose.

I'm quite sure go test compilates can spawn themselves, I'm doing it on many platforms.

But, the test setup I was referring to was explicitly not that: the tests are spawning the main binary, not themselves. Using bazel+runfiles this is pretty easy to do. With the pure Go build tool, I'm not sure what approach I'd use to "guarantee" that I get a binary build for the same environment as the test.

i think they validate less with TDD; if you tell them a bare bones spec to validate they tend to write just that. if you write the test after, then their testing is causally conditioned on what was written. if you are going to write tests, it seems like teat first is way better than test last.