it's like having functions, but with someone to write the function for you. The thing with the market is that you'd know that the code you get is verifiably accurate and thus, your software will have no bugs.

So, if the signature is fixed, why not just write the function and ship it in something like, i don't know, a standard library? ;)

That function might be accurate, but its usage might not be. It's a bold (and possibly incorrect) claim that the software composed of accurate units will not have any bugs.

We don't maintain that this system makes bugs impossible. Rather, the system provides an environment in which bugs are highly unlikely to emerge.

In this system, developers are incentivised with the prospect of direct payment to deliver a correct fragment. If we assume that game theory's rationality will prevail, I'm sure you can see how (in a perfect world), all fragments will be correct. However, we know the world isn't perfect and that there will always be an irrational player who is motivated by things other than direct remuneration... a player who has malicious or duplicitous intent.

There are three pieces of good news regarding how the system deals with these players: (1) The first is that it is actually a good deal more difficult for a bad actor to actually produce, well... bad (binary) code, compared with current methods. In this system, every agent provides its service by contracting other agents. There is no glue code in between; no opportunity for a developer to 'write' additional (malicious) code. If a developer wanted to create an agent that 'injects' malicious code, he would have to do so by contracting agents to design and 'inject' that code. Then, the developer would have to deploy that agent to the network where it would try and directly compete with other legitimate agents, agents with good reputations and a solid history of successfully completed contracts.

(2) The second piece of good news is that although these irrational players technically can enter the system and build an agent, their time will be extremely short-lived. Because of the recursive nature of the system, it has near-perfect accountability. Malicious players are easily spotted and basically ostracised by the wider compiler community. (Who would want to contract an agent that is known to return faulty/malicious fragments?)

(3) The third piece of good news is that the system itself only becomes more resilient and hostile to bad actors the longer it is operational. 'Honest' players (better yet, efficient players who cleverly optimise their agent's designs) are just as easily identified and even more handsomely rewarded. Remember how an agent achieves its service of compilation? By cleverly contracting other compile-as-a-service agents. Since these 'supplier' agents will return the smaller fragments that make up the larger fragment the agent itself returns, an agent's livelihood is dependent upon the reputation of its suppliers. This means the developer will choose its agent's suppliers very carefully, likely vetting them prior to building the agent itself. Over time, as suppliers become a known and reliable quantity, the ties between client and supplier agents are strengthened and it becomes even more difficult for a bad actor to find any kind of footing.

It is a strange concept indeed to ask someone to trust a binary that has no 'source code' to inspect! But when you know and trust the compiler of that binary, it is a no-brainer.

I'm part of the Code Valley team, and can I just say what a relief it is to see this comment. Most balk at the idea of not having source code to read and verify, but there are other ways to achieve verification, as you have stated.

OK, I have to walk back my (lightly jerkish) snark, I think. ;)

Do you mean "someone" as in the author of the template? Or as in the template itself?

What are the specific limitations of agents? What can they do? How are they written?

It's not a problem at all - no need to walk back :).

I mean "someone" as in the author of the template (to use your phrasing), yes.

> What are the specific limitations of agents? What can they do?

What each agent does, not matter where they sit in the network layers, is the same; they request information from their clients, they make some decisions and then they contract other agents. In this system, everything is a (compiling) supplier. A developer creates an agent to build on and inherit the knowledge of its suppliers, adding a little knowledge himself in the process, and ensuring that his agent returns compiled code.

Have you had a chance to check out this video (https://www.youtube.com/watch?v=qTl-V58cG1w)? It sheds a bit more light on how the service an agent performs is that agent doing its own part in a distributed compiler.

A developer can only build an agent if its suppliers exist, and if the compile-time interface protocols have been defined. Are they the sorts of limitations you meant?

> How are they written?

This system bootstrapped itself (and achieved PoC at the same time) back in 2013. Agents are built by agents. There is a special agent that sits on top of this hierarchy of agents that is designed to specifically capture a developer's requirements for their agent (what it should ask its client, what decisions it should make, and who it should contract) and translate these requirements to contracts to agents which will ultimately build that developer his agent. (The recursion is a killer sometimes, isn't it?)

This special agent that sits on top of the hierarchy is called the 'Agent-builder' and will feel to a developer like an IDE or visual programming language (designed specifically to design agents).