Three engagements, one argument.
The argument is that the automation belongs inside the building, and that it can be made affordable to run there. What follows is how Aetheric establishes both, in the order they are normally established.
Feasibility review
Not every process is worth automating, and not everything worth automating belongs on-premise. The review establishes which do, what hardware they require, and what they cost to run on it.
Concludes with a costed deployment plan and no obligation to continue.
Candidate processes identified and characterised: volume, exception rate, where the decision currently sits, which systems of record are touched, and the sensitivity of the corpus each one reads.
Token volume, context length, concurrency and latency envelope derived from the process rather than assumed, because the fleet is sized against it.
Open-weight candidates assessed against the workload rather than against a leaderboard. Capability, licence terms, quantisation behaviour, and serving cost weighed together.
Accelerator count, memory footprint, interconnect, host specification. Sized against measured requirements, not vendor configurators.
Rack space, power draw, cooling, and network segmentation assessed against what the site can actually accommodate.
Capital and running cost expressed as a cost per token at realistic utilisation, alongside the cloud alternative for the same workload.
Where the boundary sits, what crosses it, what the audit trail records, and which steps a person must still authorise.
Pilot build
One process, automated end to end, behind the client firewall. The pilot exists to prove the chain on real data and real users, not to demonstrate a model.
Client engineers work alongside Aetheric and own the system at handover.
Task decomposition, tool access under the client’s own identity model, and defined behaviour on failure. An agent that cannot be held to an identity cannot be given write access.
Extraction, classification, routing and reconciliation held in deterministic control flow. The model is used where judgement is required and nowhere else, because deterministic steps are cheaper to run and easier to defend.
Read and write paths into the systems of record, with the source system’s permissions carried through rather than re-implemented.
Scheduling, queueing, retries and idempotency. Most of what separates a demonstration from an automation lives here rather than in the model.
Where a person authorises, corrects, or overrides, defined as part of the design rather than added after an incident.
Inference server, scheduler, and routing configured for the workload. Continuous batching and cache behaviour tuned against the observed traffic shape.
Indexing and retrieval over sensitive corpora with permissions preserved end to end. A retrieval layer that ignores the source system’s access controls is a data breach waiting for an audit.
A held-out set drawn from client data, scored on the criteria the business cares about, run as a gate rather than as a report.
Prompt, retrieval, response, and identity recorded to a standard that survives a regulator asking why a particular answer was given.
Runbooks, architecture documentation, evaluation suites, and working sessions with the client engineers who will operate the system.
Most on-premise deployments run far below the capacity already paid for.
An automation is only worth running if it costs less than the work it replaces, and that comparison is decided by the inference bill underneath it.
The hardware is a sunk cost from the day it is racked. Cloud inference is a marginal cost on every request. Comparing the two as though they were the same kind of number is what makes on-premise AI look expensive, and it is why the comparison is usually made by procurement rather than by engineering.
The number that matters is utilisation. An accelerator idling between requests costs the same as one saturated. Batching, cache reuse, quantisation, and routing smaller workloads to smaller models all move the same lever, and the saving compounds across every workload sharing the fleet.
Aetheric measures cost per token before the optimisation work starts, and reports it afterwards.
Continuous batching and scheduling
Quantisation and weight format
Cache reuse and prefix sharing
Routing by workload difficulty
Optimisation retainer
Once a deployment is live, the cost per token is a moving number. The retainer exists to keep moving it in one direction.
Priced against the saving it produces.
Engine and configuration revisited as workloads change. Scheduling policy, concurrency limits, and memory allocation tuned against measured traffic.
Weight and activation formats trialled against the evaluation set, so the tradeoff is a measured one rather than an assumed one.
Cheaper models carrying the requests that do not need the expensive one, with the routing decision itself evaluated.
Steps moved out of the model and into deterministic code wherever the output allows it. The cheapest token is the one not generated.
Cost per token, cost per completed process, utilisation and evaluation scores reported on the same cadence, so the effect of each change is attributable.
The review is the place to start.
Fixed fee, costed plan, no obligation to continue. Aetheric works under NDA from first contact.
Request a technical review