chris_marino

I downvoted it because I thought it was a bot response. Did not realize you were referring to cli-printing-press. The main difference is that printing press caches a local copy of data heavy sites like Discord channels, ESPN, etc. and creates a CLI for that API.

aclif produces a single CLI with a unified grammar for all APIs, plus support for canonical names (fed by external semantic data layers) and unified auth. It targets enterprise SaaS APIs.

My response was simplified because your question was basic. OpenClaw was one example that fit the pattern, not a claim that every deployment holds the credential in the sandbox. Injection proxies exist and I should have said so. As for showing the data for advantages, I'll refer you to Anthropic and Cloudflare's Code Mode

https://www.anthropic.com/engineering/code-execution-with-mc... https://blog.cloudflare.com/code-mode-mcp/

We have our own, but will defer to 3rd party evidence.

Reinventing progressive disclosure is definitely part of this, but that's only one element of the approach. To be clear, this is all based on what we use internally, deployed in a particular way within our platform. Will leave it up to others to determine how useful it may be for them.

As for authz, that's what the rest of our system does and is beyond the scope of the aclif effort.

In many cases, the agent does hold the credential. When you authorize OpenClaw to read your gMail, OpenClaw has the credential. This is absolutely a poor practice, but common, nevertheless.

As for using the 'same tool', what I meant was that you the agent doesn't have to pick the tool at all. There is just one: the aclif CLI. Not separate tools for Salesforce, Docusign, Workday, etc that the agent needs to learn (and possibly mess up). Just the one aclif tool. Same grammar for all external services. Less agent inference the better.

Finally, alif CLIs support individual auth so a request can use SSO identities and fetch a token from a secrets value. The CLI holds the secret. If you deploy the CLI on a host or gateway, the agent never sees it.

I thought I made it clear right up front. 'Why agents need their own CLI'

What's not clear about that?

The command structure is provider/topic/command. Taken literally from the oclif framework, with the provider simply being a topic namespace. Haven't needed to pipe anything since in our deployments, the agent makes a call to the gateway via a command API so a pipe wouldn't be possible between commands

LOL.

The objectives are to reduce/eliminate as much inference variability as possible. A side benefit is that inference costs collapse as well.

It is used internally for what we call 'compiled workflow agents' where no inference is necessary. An agent composer determines the exact command at design time. That is part of a discovery loop that can introspect the service to construct the command.

More here. https://www.promptone.ai/resources/downloads/

Yes. But any coding agent can do this in a matter of minutes. There is an example prompt and corresponding Skill.md in the repo.

https://github.com/agent-cli-framework/aclif/blob/main/docs/...

https://github.com/agent-cli-framework/aclif/blob/main/.clau...

We found after deploying many enterprise agents that letting the model choose tools at run time can cause problems. The agent holds the credential and sometimes chooses the wrong tool. Using the same tool every time prevents this.

Most agents that automate enterprise workflows run a defined process: on a schedule, or on every new record or update. Those agents should never choose their own tools. Unlike an ad-hoc or exploratory research agent, a workflow agent should have its commands chosen, validated, and fixed at design time.

Don't want to split hairs here, but SOX was pre-GFC, so I'm not attributing it to only post-GFC. My first-hand experience discussing personal liability with a BoD lasted about 3 seconds. LOL.

Sure. SOX reg sec 302 and 404. Section 302 is a 100% dealbreaker for most companies, so I stand by my 'impossible' threshold. My comment was simply shorthand for all the upfront and downstream costs of going public, combined with fewer exit alternatives. Auditor/directors increased/personal liability, litigious shareholders, time and attention of management, etc. And, to your point, the lower cost of capital from growth investors. But that wasn't always the case. Certainly not true during the dot-com bubble (pre-SOX). I'll leave it to the academics to try to and isolate causality.

The article does not mention or address an important contributor to the current state of VC. The increase in regulations, post GFC, made it impractical/impossible for small companies to go public. And, until recently M&A was actively avoided. The alternative was to stay private longer offering higher returns for private investors wanting to capture a (previously non-existent) illiquidity premium. The co-dependency of companies and growth VC fueled an entirely new asset class (that many still call VC). As well as 100s of overfunded zombie unicorns.

Today, the AI boom is a perfect storm of opportunity to put $Ts to work in frontier model AI Cos.

"In recent years, as private markets inflated, the default behavior switched to remaining private and absorbing more capital (to justify more VC fee income). This has resulted in fewer IPOs, and worsening prospects post-IPO for venture-backed companies."

https://x.com/credistick/status/2092259921177804930

So, maybe more regulation is not the answer.

Salesforce, like every large enterprise software company, has a formal (and strict) End of Life process. It starts with an announcement like this indicating End of Sales, then once the contract obligations are met, they can end support, then EoL.

There is no way they can avoid this kind of public notice.

This news from Heroku does not come as any surprise to the people that were there (as I was). Lots of moving parts and second guessing (that I won't share), but one thing I will say is: Incentives matter.

The seeds of this outcome were planted years ago when sales comp plans changed. When a sales rep can hit their target by simply converting the way an existing customer gets billed, none of them look for new business. Don't need new leads. Don't need to win competitive deals. But finding new customers and losing opportunities are the only things that signal/drive innovation. But from a budgeting perspective, why increase investment in a product that already hits/exceeds their sales targets?

Over time sales targets get met, but the product doesn't advance. By the time all existing customers that can convert have converted, the product is no longer competitive. Like bankruptcy, it comes gradually, then suddenly.

I knew that. What I didn't know was if either of these could apply network policy to these endpoints. Guessing that since they each require their own CNI, there will be probs. So, whether the CNI uses iptables, or not, not clear how network policy API can be enforced.

>The ARP table might be bigger, but thats a different issue.

But this is the problem that most designs are trying to solve. Large L2s are notoriously fragile. 1,000 nodes, 50-100 pods/node is a lot of ARPs. And sometimes you want partitions between endpoints for security/isolation.

I agree with you about static assignment of addresses. But that's why (most) CNIs work with a controller of some kind for IPAM.

IMO, the problem complexity is hard to compress. You need to distribute/manage MAC addresses, routes, and/or state. Different designs would favor one over another.

It all about trade offs. We've built a CNI for k8s and have looked into all of the techniques described. It seems that Lyft's design is a direct reflection of their requirements.

To the extent your requirement match theirs, this could be a good alternative. The most significant in my mind is that it's meant to be used in conjunction with Envoy. Envoy itself has its own set of design tradeoffs as well.

For example, Lyft currently uses 'service-assigned EC2 instances'. Not hard to see how this starting point would influence the design. The Envoy/Istio model of proxy per pod also reflects this kind of workload partitioning. Obviously, a design for a small number of pods (each with their own proxy) per instance is going to be very different from one that needs to handle 100 pods (and their IPs), or more, per instance.

Another is that k8s network policy can't be applied since the 'Kubernetes Services see connections from a node’s source IP instead of the Pod’s source IP'. But I don't think this CNI is intended to work with any other network policy API enforcement mechanism. Romana (the project I work on) and the other CNI providers that use iptables to enforce network policy rely on seeing the pod's source IP.

Again, this might be fine if you're running Envoy. On the other hand, L3 filtering on the host might be important.

Also, this design requires that 'CNI plugins communicate with AWS networking APIs to provision network resources for Pods'. This may or may not be something you want your instances to do.

FWIW, Romana lets you build clusters larger than 50 nodes without an overlay or more 'exotic networking techniques' or 'massive' complexity. It does it via simple route aggregation, completely standard networking.

> Just divide up whatever IP network you're using (e.g. 10/8) and make sure you allocate "enough" to each rack/whatever.

Easier said than done. Most datacenters are bit more deliberate about allocating addresses and hand them out in non-contiguous CIDRs. The VLAN mentality is still very prevalent. Getting a /20 at a time is pretty common.

Using overlapping IPs puts you right back into the overlay model.

>Assuming everything is nice and hierarchical, you can easily aggregate an entire rack to a single prefix.

Yes, exactly. The trick then becomes how to you ensure that endpoints that get created within the rack get an IP from the prefix? Romana (the project I work on) does this. It lets you capture your network topology for exactly this reason. This is especially important if/when you must filter routes at ToR.

Both the Lyft and AWS CNIs use ENIs, Romana's CNI does not. But more specifically, vpc-router works along with Romana's IPAM to aggregate routes so that each VPC route can forward traffic for multiple instances. So, instead of one route per instance, you need only 1 routes per n instances. Where n is set by how much aggregation you want (configurable).

The net effect is that you can build large clusters without running out of VPC routes and no overlay is needed when traffic crosses AZs.

When a route is used to forward traffic for multiple instances, the target instance acts as router and forwards traffic to the final destination instance. This works because instances within an AZ have routes installed on them to the pod CIDRs on the other instances in the zone, so any one of them can perform this forwarding function.

Romana only piggybacks routes when there are no more VPC routes available, so for small cluster it's just like kubenet. For large clusters routes it uses all the instances to forward traffic so that none of them become a bottleneck.

We ran some performance benchmarks applying network policy to Kubernetes pods. Found that latency was (nearly) independent of the number of iptable rules applied. This is because once the session is set up, connection tracking lets subsequent packets be forwarded right away.

Another solution to this problem is Romana [1] (I am part of this effort). It avoids overlays as well as BGP because it aggregate routes. It uses its own IP address management (IPAM) to maintain the route hierarchy.

The nice thing about this is that nothing has to happen for a new pod to be reachable. No /32 route distribution or BGP (or etcd) convergence, no VXLAN ID (VNID) distribution for the overlay. At some scale, route and/or VNID distribution is going to limit the speed at which new pods can be launched.

One other thing not mentioned in the blog post or in any of these comments is network policy and isolation. Kubernetes v1.3 includes the new network APIs that let you isolate namespaces. This can only be achieved with a back end network solution like Romana or Calico (some others as well).

[1] romana.io

Great post!

The results of these benchmarks do not surprise me at all. To me, they all fall in to the category of 'less (overhead) is more (performance)'. With VXLAN encap being the obvious example of greatest overhead.

I think its also worth mentioning that k8s networking is being enhanced in v1.2 to support isolation and multi-tenancy through ThirdParty resources (back end network solutions). The alternatives included in the benchmarks aren't going to be able to support these kinds of network policy as is.

And, unfortunately, things get a more complicated when you want to provide more than simple reachability (which is all that k8s asks for today). The tradeoff is to be able to control the packets with the lowest overhead possible. VXLANs will give you isolation, but at the cost of encapsulation. Stacking bridges and tunnels and distributing VNIDs/routes not only introduces more latency, but becomes another multi-host coordination problem (matching tunnel IDs, etc).

We're working on a new way to build cloud native networks that avoids the encap, but still lets you control all the packets.

You can learn more at http://romana.io if you're interested.

There is still the issue of replicating content, but that's something that can be handled in a number of different ways, depending on the requirements.

Cool interface with JSON representations as well....