New comind creation

[akhilrao]

Following tinkering chat with @cpfiffer

We want some new comind invocations. Fun lil robos that go around doing things. Some should be auto-invoked by time triggers (e.g., {good-morning} may think "good morning , it's a great day to think!" at 8 am for ) or environment triggers (e.g., {threadreader} may think a summary of a sequence of thoughts that if it hasn't been updated in a little while). Others will be invoked by a user with some "params" getting passed via the user's invocation.

Examples of new invocations/actions:

• Bullet journal guy, {bulletbot}. This comind gives users an end-of-day summary of their thoughts or (more meta) how they've been thinking. Time trigger per user, maybe at 10 pm local time? Seems like this needs a user to specify a location/timezone?

• Question bot, {question}. This comind takes a thought and some surrounding thoughts as an input to generate a question about the thoughts. E.g., "{question}, take the thought linked below and 5 thoughts around it and ask a question that will make me think". This one may not be exposed to the users? So, maybe active invocation, maybe not?

• Other totally unprompted things like {wiki}; whole purpose is to get useful things into the database. Think about these more. If {question} is given a time/environmental trigger may qualify for this. Could also do something like {gutenberg}, a comind that randomly tells a user about a free book available on project gutenberg with a short summary.

[akhilrao]

{question} would be nice paired with {answer}, a comind with similar structure but instead takes in input and questions to generate answers. The questions don't have to be from {question}, could be from other thoughts. But there could also be a {question}-{answer} flow where they both get the same user input.

To customize responses to users, it would be helpful to have some sort of comind that assesses/reshapes other cominds' thoughts to be "more pleasing" to the user posing the request. Not sure what this one would be called or how this would work yet.

[cpfiffer]

I like the invocations for {question} and {answer} as general tools.

Ideally, we would run these for almost every new thought. There should be kind of a "flowering" of new thoughts that are generated whenever you post anything.

Some of the new thoughts that are generated by language models should probably be marked private. Private thoughts here would never be used for the user when generating some reason such, but the language model has access to a private knowledge graph that includes the results from question prompts and answer results.

For the answer prompt, we would flag the end result as being public or directly sharing it with the user in a private setting. Then we benefit from having explicit chain of thought reasoning all inside of the framework of comind, but only expose things to the user that it's relevant for them to see.

General purpose tools

In general having a set of very simple verbs like question and answer is probably the direction that we want to go. A user should be able to specify a rough program of language that accomplishes some arbitrary language task.

Musings:

• {research}, whiches performs a series of actions required to answer a natural language query like "what are normalizing flows". The result would vary from

• {expand} provides more exposition.

• {simplify} reduces a thought to its core concept, point, or theme.

• {snappy} makes the resulting prompt super short -- get rid of AI assistant fluff.

• {do} would be a nested call, intended to be applied in various steps. For example, the {research} keyword might apply {do} to a bullet-pointed list of tasks, and {do} would handle dispatching each task to a separate process. Do is intended to force action, like converting an outline of a document section into a full document.

• {copyedit} would handle typos, grammar, capitalization, etc.

• {high-level} puts things in abstract terms, like an overview of a statistical model. The ELI5 verb.

• {low-level} is the opposite -- it makes something nitty-gritty and down to the details.

• {yes-no} makes a thought that contains either yes, no, or unknown in response to the invoking thought. Used for reducing natural language response to queries like "Yes, normalizing flows are built on neural networks". This is clearly an affirmative, but we need a simple toggle to verify that something contains a yes. This is useful downstream when you want to do standard boolean control flow (if yes, if no, if unknown).

Each of these could call any other, and we can specify arbitrary control flows for them that handle possibly a very complex series of natural language tasks.

[cpfiffer]

In part, all this stuff is what colang is for. Colang is intended to provide a series of language operations in the form of composable functions.