Parvat, our virtual CTO

In a studio that hosts applications for several clients, every question ends up with the same person, the one who plays the role of technical director: where is this mandate at? why is this service stopped? what did we decide with this client? The answers live in six places: the task tracker, the code, the documents, the emails, the meetings and the hosting.

The one who knows them all is a single person, and they are not always available. Everyone else searches, asks, waits, and does not always know where the answer they get comes from.

Parvat is our virtual technical director. You ask it a question in plain language. It starts by consulting the company map, which says where each piece of information lives, then reads the tools concerned: tasks and code, documents, emails, meetings, hosting, and the servers, read only. It cross-checks, then answers. Every fact points to its source, and what it did not find is written "not found", never guessed.

It has two modes. By default, it answers read only. On request, it can also prepare the next step in a reversible way: an email draft, a note, an issue, a document in a "to approve" folder. Any action that cannot be undone (a send, a merge, a deployment, a deletion, a billing change) becomes a proposed action, with the role of the person who must take it.

When only a team member can answer, or when it is urgent, it can call them by phone. It runs on Appstrate, our open source platform.

Five rules, written down rather than left to intuition:

• Every fact has its source. An answer without the place where the information was read is only a rumor. The reader must be able to check.
• Read only by default. It looks, it restarts nothing and changes nothing. Reversible writes come only on request.
• Reversible, it prepares; irreversible, it proposes. A draft can be thrown away. What cannot be undone goes back to a person.
• A client's server belongs to the client. It reads, changes nothing, and never copies a secret: it only says that one exists and where.
• When only a person knows, it calls them. If the question names a team member as the one who decides and no source holds their answer, it calls them rather than answering "not found". Never anyone outside the team.

An imagined request (illustrative example, fictional content). Question: "Why has a client's application been unreachable since this morning, and where does their mandate stand?"

• Finding. The service has been stopped since last night (source: the hosting).
• Lead. A release went out just before it stopped (source: the code tracker).
• Mandate. Two tasks remain open before delivery (source: the mandate's milestone).
• Proposed to a person. Restarting the service, because that cannot be undone.
• Prepared, if asked. An issue describing the problem, and a draft message to the client.

• A map before the tools. The agent's first move is to know where each piece of information lives: without it, a broad agent searches everywhere and finds by chance.
• Trust comes from the source, not from the tone. A reliable assistant says where each piece of information comes from, and admits what it did not find.
• The line between reversible and irreversible is easier to hold than a long list of prohibitions.
• Knowing when to call a human is part of the answer. When nobody else knows, the right answer is sometimes a question put to the right person.

The same pattern works for any role that questions converge on: a technical director, an operations manager, an IT contact. Give the agent read access to the tools and a map of where each piece of information lives, demand the source of every fact, and keep for a person anything that cannot be undone.