Skills vs Conversations and Background Work

A regular conversation is one-off — the task is described each time and the platform responds in real time. Background work handles heavier tasks behind the scenes so work can continue while the platform processes. A Skill combines both: it stores the process to be followed so it never needs to be described again, then executes it as background work against whatever documents are provided.

The short version: conversations are disposable, Skills are persistent.

Three Ways to Work with the Platform

Regular Conversation

A conversation is an interactive, back-and-forth exchange with Ellie. Type what is needed, Ellie responds, and the output can be refined from there. This is the right choice for ad hoc questions, one-time analysis, or exploratory work where the goal is still being defined.

For example, pasting a lease clause into a conversation and asking Ellie to explain a co-tenancy provision, or asking her to compare two cap rate assumptions for a specific deal. There is no stored process — if the same thing is needed tomorrow, it needs to be described again.

Background Work

Some tasks take longer than a live conversation allows. When Ellie is asked to handle something complex — say, reading through a lengthy offering memorandum and producing a summary — the platform may process it as background work. There is no need to wait in the thread; other tasks can continue and the results will be ready when returning.

Background work is still one-off. The platform follows the instructions given in that conversation but does not remember them for next time.

Skills

A Skill is a stored, repeatable process. It is defined once — the steps, the rules, the edge cases, the output format — with any reference documents it needs (templates, policies, examples) attached. From that point forward, anyone the Skill is shared with can run it against new documents and get the same structured output every time.

Skills run as background work, so the same behind-the-scenes processing applies. The difference is that the instructions are persistent — the approach never needs to be re-explained, because the Skill already knows it.

When the Distinction Matters: A Practical Example

Suppose a team receives a new set of executed leases for a multi-tenant acquisition.

In a conversation, an analyst might paste one lease into a thread and ask Ellie to pull out the tenant name, lease term, base rent, escalation structure, and renewal options. Ellie will do it well — but the next analyst who does the same thing may describe the fields differently, miss a field, or get a different output format. And with forty leases, the same instructions are being copied and pasted forty times.

With a Skill, the abstraction process is defined once: the exact fields to extract, how to handle edge cases like percentage rent or co-tenancy triggers, and the output format (say, a standardised table in Excel). Every lease run through that Skill produces the same structured result, regardless of who runs it. The process is documented, consistent, and no longer dependent on any one person remembering how it should work.

That is the compounding value. The effort of defining the Skill pays off every time it runs — across every deal, every analyst, every quarter.

💡 Tip: If Ellie is being given the same instructions more than twice, that process is a strong candidate for a Skill. The upfront investment in defining it will save significant time and reduce inconsistency across the team.

Quick Comparison

Related articles

• What are Skills and What Can They Do

• How to Create a New Skill

• Running a Skill