From Electrons to Artefacts

A contract. A film. A poem. A working program. Each can end up as a file, yet each asks something different of the system that makes it. Thinking of LLMs as transformers of electrons into artefacts helps us see the whole machine: the energy, the model, the tools, the person directing them, and the result that finally matters.

The phrase is deliberately a metaphor. Electricity powers computation; trained parameters, software, source material and human intentions give that computation direction. Electrons do not contain a contract or a song waiting to be extracted. The interesting transformation is how a physical infrastructure, guided through language, becomes a cultural or professional object.

Here, an artefact means a socio-cultural production that can be represented as bits and experienced through a digital device: a contract, video, image, poem, song, blog article, LinkedIn post, spreadsheet or program. This is the definition we use in this essay, rather than a claim that all human production is digital.

An apple is outside that definition. So is a hug. Their photograph, description or simulation may be digital artefacts, but does not deliver their physical experience. This boundary matters: making the representation of something is different from making the thing itself.

To map the system, imagine a racing team. Energy, refinery, fuel supply, motor, chassis, driver, race result. Each has a role; none explains the performance alone. The seven layers below adapt that analogy to AI. Read them as dependencies and controls, with feedback between them, rather than an assembly line that automatically produces useful work.

The apparent weightlessness of a generated document hides an electrical system. In its April 2026 update, the International Energy Agency puts global data-centre electricity consumption at 485 TWh in 2025 and projects 950 TWh in 2030. Those figures cover all data centres, not AI alone; the second is a projection.

In the racing analogy, this is raw energy. But electricity is supplied by a mix of sources, including renewables, nuclear power and fossil fuels. Calling this layer simply “fossilised carbon” would be misleading. Its practical constraints include available power and grid connections, before anyone even writes a prompt.

Electricity powers servers, GPUs and other accelerators, along with memory, networks, storage and cooling. These machines execute the numerical operations of the model. The refinery analogy describes industrial conversion: an energy supply becomes an available capacity to compute.

That capacity already depends on an accumulated history. Training has shaped the model’s parameters; inference uses them on a particular input. The electricity consumed now does not create the system’s capabilities from scratch. The metaphor has to keep this inheritance in view: hardware, learned structure, software and the human culture represented in training material.

A language model processes and generates sequences of tokens. A token may be part of a word, a whole word or punctuation. For text generation, the model predicts successive tokens in context. The Transformer is a neural-network architecture built around attention; the name’s resemblance to an electrical transformer is a useful wordplay, not the same mechanism.

In our analogy, the model is the fuel supply and tokens are what the rest of the machine can draw on. A poem may already be delivered as text. A spreadsheet with working formulas, an edited film or a deployed program requires other operations. Depending on the system, a multimodal model may generate media directly, or the LLM may direct specialised models and software. “Language to artefact” names this wider capability, not a promise made by every text model.

The harness is the motor in this picture: the software around the model that organises its work. It supplies instructions, selects context, exposes tools and manages an execution loop. Natural language expresses the objective, but the surrounding system gives the model ways to act on files, applications and services.

A tool call makes the distinction concrete. The model proposes an operation; the application executes it and returns the result. The model can then adapt its next action. Writing code that creates a document, rendering its pages, discovering a broken layout and correcting the code is a sequence of transformations with feedback. It is more than generating a longer answer.

Consider an illustrative brief: turn source documents into a two-page report with traceable claims, a chart, an editable source and a readable PDF. The harness has to make those sources available, retain the constraints, enable file creation and expose the rendered result. A plausible final message cannot substitute for the actual files. An execution loop also needs a budget and a stopping rule; repetition alone does not guarantee progress.

A chassis holds the components together and makes a vehicle usable. The human-facing interface does something similar: it brings the brief, files, permissions, progress and result into one working environment. It may be a desktop app, a browser or a command line. Electron is one possible application framework, not a required layer and not the electrons in our title.

There is also an interface for the model: the actions it can call and the feedback it receives. In the 2024 SWE-agent study, the same GPT-4 Turbo solved 11% of 300 SWE-bench Lite tasks with a shell-only interface, against 18% with the authors’ designed interface. This historical software-engineering experiment does not predict gains for every profession. It does show that changing the environment can change results while leaving the model’s weights unchanged.

A fast car does not decide which race is worth entering. Someone has to define the destination, the constraints and an acceptable result. The initial request can be short; the underlying intent often is not. Who is the audience? Which source takes precedence? How much uncertainty can remain? What matters more here: speed, originality, fidelity or precision?

The operator can be human or AI. In an agentic system, the model may choose intermediate steps and tools; in a predefined workflow, software fixes more of that sequence. These roles can overlap: one agent can direct another, inside a harness. The seven-layer picture separates functions, not necessarily seven different products or actors.

Delegating execution still leaves a question of authority. For the work we describe here, our proposed rule is to make explicit who sets the criteria, who can authorise consequential actions and who accepts delivery. An agent’s ability to continue working is useful only within a direction someone has chosen.

The useful output is the thing someone can take away. A contract they can edit. A video that plays with the intended sound and framing. An image at the required dimensions. A program that runs in its target environment. A poem whose rhythm and voice are worth reading. Being represented as bits is our entry condition; being worth using is a further judgement.

Acceptance changes with the artefact. A numerical total can be recalculated. A cited claim can be checked against its source. A file can be opened and rendered. Originality, taste and the emotional force of a song need other forms of assessment. No single test turns all cultural production into an objective score.

The file is an output. The artefact becomes useful when it survives contact with its intended use.

GDPval offers one concrete example of evaluating deliverables. Introduced by OpenAI in September 2025, its first version covers 1,320 tasks across 44 occupations and uses blind comparisons by domain experts. It is a provider-built benchmark, with one-shot tasks that do not capture the full ambiguity or iteration of a client engagement. Its useful lesson here is the choice of object: assess the work produced.

For an organisation, we propose tracking the cost per accepted artefact, with acceptance criteria defined for the task. Count model use, tools, infrastructure, human review and rework. Track delivery time and quality alongside that cost. These are management choices, not a universal benchmark; comparisons make sense only for comparable work at a comparable standard.

This shifts attention to the full system. If the expected deliverable is absent, delivery failed. If a document opens but its figures are wrong, the work needs revision. If all mechanical checks pass but the film says nothing, a different judgement remains. Tests, expert review and audience response reveal different aspects of the result. The transcript is evidence of a process; the artefact is what that process must answer for.

A race has a defined track and a finish line. Cultural and professional work often requires deciding what the finish line should be. The analogy also hides the people, data and accumulated knowledge behind the machine. It remains useful if we remember those limits: electricity enables the process, the model contributes capabilities, and the whole system determines what can be delivered.

For ogram, this gives a concrete direction: work on the passage from general capability to a result that fits a particular practice. Make expertise available as context, give the model suitable tools, preserve constraints and inspect the output. Better models expand what is possible. Better systems help that possibility arrive, intact, in someone’s hands.