Obviously Phil should choose the names since he did the work. That said, I think "async" is a good name. But that also said, "app" is one of the Earth words I most regret smuggling into Urbit. There are many good ideas in the conceptual dumpster marked "app," but it is also a very good way to import unexamined assumptions and other terrestrial biohazards. One of the many definitional issues with the word "app" is that "app" conflates the code of an application with its data. In a programming environment which is genuinely imperative there is some cause for this. But the state of an asynchronous transaction, though it contains cores, is still a noun. I also hate all allusive, poetic, and short terminology. Galen converted me completely to normcore. I would call the state of an asynchronous transaction a *conversation*. I would call the code which manages the transaction a "driver". Phil has suggested *verse* for *conversation* -- I also hate abbreviations, but I am ok with *convo* because it is normal SMS slang. Replace "driver" and "conversation" below with whatever names are chosen. In my mind the basic function of a driver is to control a non-Urbit, or non-Urbity, service from Urbit. A driver is a client for any foreign, or otherwise weird or gnarly, service. The top-end case could be Let's Encrypt -- because nothing could be gnarlier than ACME. A normal Urbit service -- an "agent" (or "%gall app") should be declarative, not imperative. Communication between agents is peer-to-peer CQRS. One message is one command is one transaction. This is the way Urbit should work, but it's not the way the world works -- which is why Urbit needs tapps/drivers. Declarative agents are generally more manageable and just plain better than imperative drivers. But solving an imperative problem declaratively is an exercise in masochism. It is theoretically possible to build either form within the other, but agents' clean, coreless state is more fundamental. However, there may be execution layers which execute the imperative form directly -- for example, the dojo could really do fun things with drivers. Another unexamined assumption that can flow from the use of the word "app" is the expectation that an agent, if it has to talk with Earth and thus has to resort to a driver, has to contain only one driver, or only one conversation per driver. Unfortunately, present-day %gall apps are absolutely terrible at being declarative agents. Things the programmer doesn't declare: outgoing subscriptions; inbound subscription routes; card protocols; hierarchical sub-agent structure; other external resource requests... not being declared, this is not visible to the execution engine (%gall), and the programmer has to work it all by hand. Until complex agents -- of the complexity of %talk -- can be written without any of this manual nonsense, the simplicity of an imperative client may draw too much functionality out of agents and into drivers. If this threat is productive, it will inspire some improvement in agents. Another important case for drivers is providing a gateway to weird, gnarly, foreign services, so that Urbit can command and subscribe to them as if they were nice Urbity native services. Many of these drivers already exist, implemented as declarative state machines -- which is just wrong. Here again the engine perhaps can and should understand drivers and conversations directly, not wrapped in a declarative agent at all.