One of my engineering highlights was Russ reviewing a few of my contributions to Golang (to the core http library). He&#x27;s a super cool and nice guy. I don&#x27;t really write that much Go anymore, but it was a fun &amp; cute language when it first came out.

I’m so happy Russ still contributes even though he isn’t lead anymore. I always enjoy reading his blog posts

I’d love to see how that compares to zmij: <a href="https:&#x2F;&#x2F;github.com&#x2F;dtolnay&#x2F;dtoa-benchmark" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dtolnay&#x2F;dtoa-benchmark</a>

Not mentioned: Floating-point parsing and formatting now uses Russ Cox&#x27;s uscale algorithm.<a href="https:&#x2F;&#x2F;research.swtch.com&#x2F;fp" rel="nofollow">https:&#x2F;&#x2F;research.swtch.com&#x2F;fp</a><a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;blob&#x2F;go1.27.0&#x2F;src&#x2F;internal&#x2F;strconv&#x2F;uscale.go" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;blob&#x2F;go1.27.0&#x2F;src&#x2F;internal&#x2F;strc...</a>

Yes, and at that time the answer was &quot;move over where?&quot; now it&#x27;s 2026 and x-wing is a draft still

Yeah the deadline to move everything is drawing near I am actually not impressed by how fast things are going but all progress is good.

its ok we are still rawdogging ftp every day in the business world. The fax machines of the future truly

While I&#x27;m highly sympathetic to competing priorities crowding out movement to pq cryptography. At the same time it&#x27;s not sudden at all. It&#x27;s been 10 years since nist first said &quot;move shit over&quot;?

This person was public on the recent nist list against hybrid solutions. I simply don&#x27;t understand why they would oppose the safer option. Yes I&#x27;ve read the mailing list, it just all seems quite suspicious.

US Government is starting to push hard so code first needs to support it.

Ok, but when is it coming to our web browsers and email clients?

The .NET team have been similarly busy on post-quantum lately, it completely dominated the .NET API reviews for the dotnet 11 release.It seems there&#x27;s a big push happening behind the scenes.

I love how proactive the crypto team is about post quantum. They released <a href="https:&#x2F;&#x2F;pkg.go.dev&#x2F;crypto&#x2F;mldsa" rel="nofollow">https:&#x2F;&#x2F;pkg.go.dev&#x2F;crypto&#x2F;mldsa</a>. The lead maintainer Filippo Valsorda wrote a nice piece here[1] to urge the tech world to start deploying good enough versions of post quantum crypto.[1] <a href="https:&#x2F;&#x2F;words.filippo.io&#x2F;crqc-timeline&#x2F;" rel="nofollow">https:&#x2F;&#x2F;words.filippo.io&#x2F;crqc-timeline&#x2F;</a>

The database&#x2F;sql package gained native support[1] for the uuid.UUID type so it will Just Work even without the methods. This probably should have been mentioned in the release notes and database&#x2F;sql package docs.[1] <a href="https:&#x2F;&#x2F;cs.opensource.google&#x2F;go&#x2F;go&#x2F;+&#x2F;refs&#x2F;tags&#x2F;go1.27.0:src&#x2F;database&#x2F;sql&#x2F;convert.go;l=270-280" rel="nofollow">https:&#x2F;&#x2F;cs.opensource.google&#x2F;go&#x2F;go&#x2F;+&#x2F;refs&#x2F;tags&#x2F;go1.27.0:src&#x2F;...</a>

Oooof… well played go team, well played.

Unfortunately for people SELECTing UUIDs out of a DB directly into a uuid struct, the built-in uuid structs don&#x27;t implement the necessary interface for that, so you&#x27;ll have to continue using the google package, or a plain string.

will &#x27;go fix&#x27; take care of this?

Brace for a wave of drive-by pull-requests swapping google&#x2F;uuid [1] out for the now-standard uuid package [2].Kubernetes project will be the first one [3] I guarantee it.[1] <a href="https:&#x2F;&#x2F;pkg.go.dev&#x2F;github.com&#x2F;google&#x2F;uuid" rel="nofollow">https:&#x2F;&#x2F;pkg.go.dev&#x2F;github.com&#x2F;google&#x2F;uuid</a>[2] <a href="https:&#x2F;&#x2F;go.dev&#x2F;pkg&#x2F;uuid" rel="nofollow">https:&#x2F;&#x2F;go.dev&#x2F;pkg&#x2F;uuid</a>[3] <a href="https:&#x2F;&#x2F;github.com&#x2F;kubernetes&#x2F;kubernetes&#x2F;blob&#x2F;2220c3853a2402ffc0502995c49b383f84ae8ceb&#x2F;go.mod#L36" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kubernetes&#x2F;kubernetes&#x2F;blob&#x2F;2220c3853a2402...</a>[4] <a href="https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;uuid&#x2F;issues&#x2F;221" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;uuid&#x2F;issues&#x2F;221</a>

Can proper Result&#x2F;Option types be created for Go now?

I wrote a blog on it if you&#x27;re interested: <a href="https:&#x2F;&#x2F;xeoncross.com&#x2F;2026&#x2F;better_go_handlers.html" rel="nofollow">https:&#x2F;&#x2F;xeoncross.com&#x2F;2026&#x2F;better_go_handlers.html</a>

&gt; First, generic methods are now supported
&gt; Generic functions can now be used without explicit type argumentsGreat! This was an ergonomic code issue I hit when trying to create a universal handler&#x2F;controller generic that could hydrate&#x2F;populate function arguments (from a request body) without having an actual copy of the arguments: <a href="https:&#x2F;&#x2F;github.com&#x2F;xeoncross&#x2F;mid&#x2F;blob&#x2F;main&#x2F;handler.go#L12" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;xeoncross&#x2F;mid&#x2F;blob&#x2F;main&#x2F;handler.go#L12</a>

&gt; Syntax highlighting is juvenile. When I was a child, I was taught
arithmetic using colored rods
(<a href="http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Cuisenaire_rods" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Cuisenaire_rods</a>). I grew up and today I
use monochromatic numerals.<a href="https:&#x2F;&#x2F;groups.google.com&#x2F;g&#x2F;golang-nuts&#x2F;c&#x2F;hJHCAaiL0so&#x2F;m&#x2F;kG3BHV6QFfIJ" rel="nofollow">https:&#x2F;&#x2F;groups.google.com&#x2F;g&#x2F;golang-nuts&#x2F;c&#x2F;hJHCAaiL0so&#x2F;m&#x2F;kG3B...</a>

What is childish is holding up one guy&#x27;s editor preferences as a religious sacrament when 99.9% of your readers have different preferences.

That makes sense as a personal preference for him, but it&#x27;s odd for that to still be the company&#x2F;project stance. Like, surely he knows he&#x27;s the minority for not wanting highlighting?

that&#x27;s an extremely odd explanation and it makes me think that he has some hidden PTSD. it&#x27;s also insane that one person&#x27;s preference trumps the rest of the world&#x27;s.

I understand and respect this position. I think syntax highlighting
is a highly subjective matter, bordering on personal preference with regard to shell interactions, editor configurations, bindings, shortcuts, snippets, and the like. It&#x27;s also... insignificant somehow, like quibbles over formatting rules that Go settled once and for all with `go fmt`.I often prefer not to enable syntax highlighting just for color. Occasionally I&#x27;d choose some minimal theme that only highlights string literals and keywords. So it has two or three colors. But some of the color schemes I see are a festival of lights where every special element of syntax has its own color.
I don&#x27;t understand how that is supposed to help me parse anything and why the rules are complex. The `range` keyword needs to be purple, and `chan` must be navy blue. Why exactly? And every site has a different color scheme? There is no consensus, and there shouldn&#x27;t be.For a serious community-driven project like Go, dealing with the question of syntax highlighting is strange. The creators deliberately avoided the questions of IDEs and editors for Go, leaving them to the community. I think the same principle applies here.

There&#x27;s a reason for this. Rob Pike was asked about it and said that syntax highlighting reminds him of the bright colors of children&#x27;s toys and he personally disables it so that he can focus on the text.I don&#x27;t know why it&#x27;s still like that but that&#x27;s the original reasoning.

I just have a tampermonkey profile for go.dev to fix that for me.

When I started learning Go I went all in including using the recommended editor (acme editor) which has no syntax highlighting, no autocomplete and a very different way of writing code. My production went down a lot but the quality of the code went up a lot.I think the lack of syntax highlighting was one reason for that. It makes you think more about the code you write and how it should compose, while a fully fledged IDE encourages you to just throw more code at the problem.I think the ACME way should be used for love of code and ideally when you want to create libraries that stand the test of time.
When you just want to get things done fast bring the full IDE and now some LLM vibes and it’s done.

I love these release notes but I really wish they would add syntax highlighting to the Go blog. I&#x27;m always a little bit surprised&#x2F;disappointed whenever I land on a go.dev link since I know the code will be just a little harder to visually parse than it needs to be.

It will be very nice working with code generators like oapi-codegen that can generate either nested structs or very unwieldy struct names. So big in that context, but like you said just a nice qol improvement most of the time.

This is quite a QoL issue, but is it big? Nothing changes from functional point of view.

&gt; Second, a key in a struct literal may now be any valid field selector for the struct type, allowing fields in nested or embedded structs to be initialized directlyIt&#x27;s been a while since I&#x27;ve written more than anything trivial in golang, but this seems like a big deal to me. As in, I can define a struct that is consistent and reusable in other structs

Re unions:<a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;76920" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;76920</a>You might want to follow this proposal, if you aren&#x27;t already. It&#x27;s the most recent one, and it&#x27;s supported by quite a few “core members” of the Go Team. I don&#x27;t think it&#x27;ll land in 1.28, but I like the fact that it&#x27;s still a feature that&#x27;s being actively discussed.

This is only a small piece of the story for what people say when they want tagged unions. Without all of the ancillary support in the language, like exhaustive pattern matching, it really doesn&#x27;t count.

The C++ committee said the same thing, and gave us std::variant. They are painful to work with and do not really deliver most of the benefits people want.

That is a LOT of code (very ugly code, I would add) that could be replaced by `type Float = float32 | float64` in a language with actual support for union types.

Tagged unions can be implemented in user code, you dont actually need language support to use them.<a href="https:&#x2F;&#x2F;github.com&#x2F;splizard&#x2F;tagged" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;splizard&#x2F;tagged</a>

Go is extremely easy to pickup. If you know any language you probably know Go already for the most part (channels notwithstanding).I wouldn&#x27;t say it is a &quot;beautiful&quot; language however. Though that is in the eye of the beholder, I don&#x27;t think the Go designers were even really going for beauty.

Do it. It is just a beautiful language to write and much simpler to pickup than many others. I am a fan boy of course but I love Go.

This makes me want to find a side project for an excuse to give Go another try (I last used it professionally pre-generics).I do still wish it had discriminated unions (algebraic data types) and some better error handling ergonomics.

Agreed. I&#x27;ve recently translated a pangram generator project written in Rust [1] leveraging SIMD to do the same in Go [2] to see how it fairs in terms of speed - the results are pretty close. In my local machine I&#x27;m getting ~3GHz in Rust vs ~2.4GHz in Go, which I think is really impressive.[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;tuzz&#x2F;pangram-machine" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tuzz&#x2F;pangram-machine</a>[2]: <a href="https:&#x2F;&#x2F;github.com&#x2F;nkanaev&#x2F;pangram-machine-go" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;nkanaev&#x2F;pangram-machine-go</a>

“Do a breakthrough and make this SIMD fastest”

The SIMD stuff is incredible. I have been having lots of fun with it. You can use LLMs as a scalar to SIMD transpiler, it works amazingly well.Sure a SIMD expert writing assembly can probably do a better job than an LLM using these new intrinsics, but it’s still massively faster.

I&#x27;m so glad the new uuid package landed - it&#x27;s overdue but a very welcome addition! I&#x27;ve already replaced github.com&#x2F;google&#x2F;uuid with `uuid` in several projects

Ah my bad gopls is fine; I forgot to run<pre><code> go install golang.org&#x2F;x&#x2F;tools&#x2F;gopls@latest
</code></pre>
after upgrading Go itself.

Broken how? Please report an issue. The latest gopls should support generic methods.

FYI golangci-lint and gopls are both broken if you try using generic methods.

Every release CPU load becomes a bit lower. Love it :)

Full release notes: <a href="https:&#x2F;&#x2F;go.dev&#x2F;doc&#x2F;go1.27" rel="nofollow">https:&#x2F;&#x2F;go.dev&#x2F;doc&#x2F;go1.27</a>

naah.. they are just too different syntactically.. and the way programmers use them..

because functional languages already have those features?

As I&#x27;ve always said: every non-functional programming language, as it matures, it&#x27;s adoption rises in enterprise, eventually starts to become more and more like Java in terms of it&#x27;s syntax and feature-set.

I mean one thing frontier models are really good at is porting code with pretty low level of supervision. Provided there are enough fans porting packages from other ecosystems should not be a big challenge.

I don’t think launching Go today would have been better than 15 years ago.Standard ML is a perfect programming language from the 90s. It unfortunately does not have a great eco system of packages.

Obligatory XKCD reference:<a href="https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;</a>

Nice additions to go.I like to imagine that one day we&#x27;ll have a language that launched with all the features languages eventually add. The whole ecosystem of packages would be built on them instead of a legacy of more primitive language feature sets.

I know this is an extremely unwelcome comment but I just have to ask… have you considered rust? Especially for a DB.I just had excellent success migrating a go code base to rust completely AI driven. It led to a healthy performance boost too, as now I don’t need to worry about GC pressure contortions.

Generics were always planned, of course: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=rKnDgT73v8s&amp;t=3267s" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=rKnDgT73v8s&amp;t=3267s</a>Rejecting templates does not mean rejecting generics.

&gt; Generic methods are a huge win for the language. I&#x27;ve been waiting on these kinds of improvements to the type system ...It&#x27;s funny that you and many others have found the introduction of &quot;generics&quot; in Go to be highly valuable, considering one of the motivations for Go&#x27;s existence was:<pre><code> Its designers were primarily motivated by their shared dislike of C++[0]
</code></pre>
One of the language features C++ provides, &quot;templates&quot;, was explicitly rejected by the language authors as being antithetical to Go philosophy[1]. Thompson put it bluntly:<pre><code> DDJ: In the presentation before the awarding of the Japan 
 Prize today, you were quoted on the distinction between 
 reasearch and development. [The former, Thompson stated, 
 was directionless, whereas development had a specific goal 
 in mind.] So in that context, is Go experimental?
 
 KT: Yes. When the three of us [Thompson, Rob Pike, and 
 Robert Griesemer] got started, it was pure research. The 
 three of us got together and decided that we hated C++. 
 [laughter] [2]
</code></pre>
And now, years later, generics are &quot;a huge win.&quot;0 - <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Go_(programming_language)#History" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Go_(programming_language)#Hist...</a>1 - <a href="https:&#x2F;&#x2F;commandcenter.blogspot.com&#x2F;2012&#x2F;06&#x2F;less-is-exponentially-more.html" rel="nofollow">https:&#x2F;&#x2F;commandcenter.blogspot.com&#x2F;2012&#x2F;06&#x2F;less-is-exponenti...</a>2 - <a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20110521080746&#x2F;http:&#x2F;&#x2F;drdobbs.com&#x2F;open-source&#x2F;229502480" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20110521080746&#x2F;http:&#x2F;&#x2F;drdobbs.co...</a>

Generic methods are a huge win for the language. I&#x27;ve been waiting on these kinds of improvements to the type system before resuming work on my database toolkit.

New JSON is amazing, and SIMD will be big for json, audio&#x2F;video etc.

Used to code primarily in Java. Now my app stack is about 80% Go. I love that it enables lightweight application development. Glad to see the platform evolving with a focus on resource efficiency.

Generic methods finally landing is huge. Having to write a separate typed method for every integer type was one of the most annoying boilerplate patterns in Go.

Why would you say something so controversial yet so brave?

C++23 introduces std::expected, which is a simpler alternative to std::variant designed specifically for the result-or-error use case. You still don&#x27;t get pattern matching, but Go-style tuples don&#x27;t give you that either.

Not that I like go at all but because of it my C++ is starting to look like it as I am returning tuples of [result, error].I try to avoid exceptions, is there any better ways? (Variant looks a bit more complicated but could be a totally OK alternative)

Personally I feel go has many issues and is ugly as hell but the error handling is really the least of my worries.

I really want to like Go, but I can&#x27;t stand looking at Go code. The error handling is such a turn off.

I&#x27;m always amazed on how the Go team has bo faith in syntax highlighting.

true that, but we get a couple of these a year it seems, so their overall velocity is excellent, and without breaking anything. a dream language.

Minor versions are basically major versions for Go. They’ll “never” create a Go v2 because they prioritise maintaining backwards compatibility as a language feature, thus following semver rules, no majors.

I love Go because even minor versions deliver great value like this. The struct literal inits and generic methods are great conveniences to clean up clumsy boilerplate.Not to mention it’s just a dream language to work with , especially when building concurrent applications. I love engaging all of my cores. And memory is so expensive nowadays

I have been waiting for generic methods and can&#x27;t wait to use them!The `go fix` modernisers are also great, have already run them in several repos.

I have recently been spending time learning go, really really liking the language, awesome standard lib, excellent tooling and great experience.It sounds like the dumbest thing in the world, but I love the import system auto-adding stuff inside of vscode when I need it. just slick.

What exactly do you mean by &quot;goroutine termination&quot;?

does it have goroutine termination, i recently found out you need a runtime patch for it

Python is already the language everyone needs.

Go - the language no one likes, but frankly everyone needs.

A large portion of the DevOps&#x2F;Platform Engineering world uses Go.

I can imagine using it for simple web stuff. E.g. its perfect for something like Forgejo. But yeah... Seems like the world has moved on mostly.

Quarterly reminder that Go still exists.

no, it wasnt 40 upvotes in 40 minutes, it was at 8 upvotes after 34 minutes posted

Being on the HN&#x27;s homepage isn&#x27;t as simple as &quot;most upvoted articles in last X hours&quot;. They take into account upvote velocity: 40 upvotes in 40 minutes isn&#x27;t the same as 40 upvotes in 4 yours.

Would you rather have yet another LLM-generated slop article in its place instead of an article covering a major release for a widely-used language? Out of all the articles that reach the HN front page, this is the one you have a problem with?

There are some details here about the history of how generics finally came to Go: <a href="https:&#x2F;&#x2F;golang.design&#x2F;under-the-hood&#x2F;en&#x2F;part2lang&#x2F;ch08generics&#x2F;history&#x2F;" rel="nofollow">https:&#x2F;&#x2F;golang.design&#x2F;under-the-hood&#x2F;en&#x2F;part2lang&#x2F;ch08generi...</a>The tl;dr boils down to a combination of valuing both compilation speed and execution speed.

Wait generics? What changed? Why is golang accepting of generics now?

I&#x27;m pretty sure there is a silent majority of Go users who don&#x27;t want&#x2F;need&#x2F;know about generics.

I would argue that languages like Java (C#, Kotlin, etc.) strike a very good compromise between modeling ability and comprehension, which is why they are popular and people gravitate toward them.You can have more complex languages like Scala that provide stronger modeling ability, but at the cost of complexity. Golang started off as extremely naive&#x2F;simplistic, and is now converging in some ways. But it still has a ways to go: no generics on interfaces, no unions&#x2F;ADTs, no pattern matching, no proper enums, error handling leaves much to be desired, and much more.

&gt; almost seems like Go is trying to become some sort of C# or Java FrankensteinThe original Go team was trying to avoid this:&quot;Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more [...] actively borrow features from one another. They are converging into a single huge language.&quot; [0]That team has since moved on, and now Go has begun to join that convergence.The problem is that most programmers seem to want to write Java, more-or-less. New, simpler languages come along, but once they get popular, the pressure is on to turn them into Java-likes. It happened to Python and now it’s happening to Go. It takes a strong will for language maintainers to say “no”, and their language will suffer in popularity as a result - see, for example, Ruby.[0] <a href="https:&#x2F;&#x2F;go.dev&#x2F;talks&#x2F;2015&#x2F;simplicity-is-complicated.slide#5" rel="nofollow">https:&#x2F;&#x2F;go.dev&#x2F;talks&#x2F;2015&#x2F;simplicity-is-complicated.slide#5</a>

A problem was so many others were screaming about the lack of generics, as though there were not other language options that provided them.

Go genetics are still incredibly simple compared to languages with a rich type system.

Wasn&#x27;t Go supposed to be &quot;simple&quot;? I remember how Go advocates used to boast about not having generics and now it almost seems like Go is trying to become some sort of C# or Java Frankenstein. I&#x27;m not even trying to badmouth Golang - just legitimately confused.

Go 1.27

Previously: Stripe will reportedly acquire OpenRouter for $7B+ <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=49323381">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=49323381</a>

OpenRouter is joining Stripe

Turns are Better than Radians

Error by AI scribe during medical appointment leaves patient devastated

A faster way to calculate the day of the week

Manabu Kosaka's Handmade Paper Sculptures

Google replaced Git tags for certain source code with obtaining via Google Drive

Unlocking a locked/deactivated e-waste Cricut Maker

A joke domain purchase turned in geopolitical warfare

Unsloth Dynamic 3.0 GGUFs

Casio F-B100W-1A

Sol Loves to Cheat

Geolocating a random island using geometry and CUDA programming

Os8088.com: IBM XT OS now has a Browser, CP/M 2.2 with Z80 core and MS Word 1.1a

Hi HN, Jonathan &amp; Guy here from OneCLI, an agent harness built for teams, giving every employee a secured, sandboxed personal agent.Here’s what you can do with it:1. get a sandboxed agent, with all the OneCLI capabilities in place like connect your GitHub account, Gmail, Notion, or Dropbox simply from the chat.2. deterministic human in the loop approval in the chat itself for things that you need 100% control like sending an email or deleting the Linear ticket.3. manage team policy in one place, enforced across every agent in the workspace4. enjoy global connections at the team level, like shared LLM keys or service accountsHere’s a demo: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=dlW-44ntpbE" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=dlW-44ntpbE</a>We started working on this by accident, even though our careers were in the security space. We were working on a devtool called ChartDB, an open-source DB tool. When OpenClaw took off back in January, we started using it to orchestrate agents on top of ChartDB. We quickly understood there is a big issue around auth. Agents need credentials to do real work, but to give them those secrets would not be the best idea. They keep them in their memory and also write them down to local files and their sessions as plain text. And we knew that agents can easily be fooled into giving up those API keys&#x2F;secrets. So we needed some way to control the agent and stop prompt injections from tricking it into using its services for an attacker&#x27;s benefit.We created OneCLI that started as a vault for AI Agents built in Rust.We found out that most of our demand for OneCLI came from autonomous agents like Hermes, OpenClaw and NanoClaw for individuals and teams.Users looked for useful agents that do things for the person who runs them with two missing parts: 1) managing secrets and permissions. 2) and for teams - multiplayer management.We decided to pivot and provide the agent itself as a harness for teams, to give each employee an agent. We saw that teams had to deal with setting up their own harness again and again, and basically as we already had the vault as a gateway. We got the idea to provide the missing piece of the agent management out of the box and open source it (Apache-2.0, with a small enterprise exception).We&#x27;re open source first - the entire platform, not just a small portion of it like other agents, so companies can actually see the code, evaluate it, and trust it instead of taking our word for it. They run it isolated, in their own environment, fully under their control, at production quality, not a locked black box hosted somewhere else. That means the safety isn&#x27;t just a promise, it&#x27;s something they can verify themselves. Combined with real autonomy and least-privilege access, that&#x27;s what makes it something a company can fully own and trust, not just adopt.We also approach this from a company perspective rather than an individual one. Our solution manages agents on behalf of each employee, wrapped in deterministic guardrails that company admins configure through centralized policies.For the agent engine itself we’re using jcode which is the core of the agent-loop. We found out that it improves the experience and makes the agent smarter and faster.Here’s how it works:It runs on infra you control. Fully open-source, self-host or cloud in minutes.The agent never holds a real secret. It gets a placeholder. The real credential is injected at the gateway, per request, after the call is authorized. It never enters the agent&#x27;s context, memory, or logs.Enforcement outside the model. Prompts are suggestions. Policies defined by the org admin run at the network layer, outside the agent and the LLM. Block endpoints, rate limit per agent, require approval, scope per employee. The gateway decides. The agent can&#x27;t bypass it.Isolated VM per agent. Own memory, own keys, own permissions. Blast radius is one agent.Speed of the Harness: Rust engine under the agent loop.Full identity trail. Every agent is bound to an employee. Every call logged with who it acted for and which policy allowed it.Some things people are doing with the platform include:- Managing their company life cycle entirely from the sales calls, to the product side automatically open tickets to the engineering teams, that would kick the development agents to deliver and ship to production.- Operational side, like automatically hygiene the CRM after calls, sourcing leads, book meetings and manage follow ups emails.- Some of our customers also doing their entire grocery shopping using those agents and send them to take care of their chores like ordering things online.About the team: Both founders come from cybersecurity backgrounds. Jonathan spent years at Axis Security building zero trust network access. The core idea is that you never trust the client. You decide exactly what a person can reach, and you enforce it outside of them, at the network layer, so it doesn&#x27;t matter what the client tries to do. That&#x27;s how every serious company gives access to humans today. Guy was the 1st employee in Argon security doing AppSec.We would love to hear your thoughts on the move, happy to get issues open to improve and get your agent to be powerful and secure - designed for teams, not just individuals.