Skip to main content

Company

Building the governed execution layer between intent and operational change.

resh grew from the Resource Shell idea: infrastructure should expose meaningful, governable resource operations instead of forcing automation through unrestricted command surfaces.

Why resh exists

resh began with Resource Shell and a narrow technical conviction: that a system should expose meaningful, typed operations on named resources, rather than forcing every caller through a general-purpose command surface and hoping the caller is careful.

That foundation turned into a broader question. As AI agents gain the authority to change real systems, what should stand between authorization and execution? Identity answers who. Gateways and authorization decide which calls may be attempted. Automation platforms execute and report an exit code. Each covers part of the path, and resh is built around the part that follows: the moment an authorized intent becomes a consequential change to a real resource, and whether that change turned out as intended.

Our answer is governed execution.

resh is being built to make consequential operational change understandable, bounded, policy-aware, verifiable, and accountable — starting with the infrastructure that DevOps, SRE, platform, and security operations teams run.

Resource Shell (resh) is a product being developed by Miller Technology Group, LLC (opens in a new tab), a software engineering company based in Atlanta, Georgia. Miller Technology Group is currently developing the platform and running its design partner program on a pre-GA preview release.

The pieces

resh, Resource Shell, and everything in between.

Several related names appear across this site and the open-source work. Here is what each one refers to.

Miller Technology Group, LLC
The company developing resh
A software engineering company based in Atlanta, Georgia. Resource Shell (resh) is a product it is developing, alongside the custom software, integration, and automation work it does for clients.
resh
The product: a Governed Execution Platform
Resource Shell (resh) is the governed execution layer between operational intent and consequential change. It applies policy before an operation runs, executes the bounded operation, verifies the resulting state, and records the evidence.
Resource Shell
The open-source foundation of resh's resource-oriented execution model
Resource Shell established the idea that systems should expose governed, typed operations on named resources rather than unrestricted command authority. It is the origin of the resource model resh is built on.
resh-core
The runtime at the centre of that model
resh-core resolves a resource handle to a provider, applies path, policy, and risk gates, executes through one common pipeline, and records the operation. Provider surfaces are experimental while the runtime contracts settle.
resh-cli
The command-line interface
resh-cli is the `resh` binary. It registers providers and drives resource operations through the same runtime pipeline, so a person at a terminal and an automated caller cross the same governed boundary.
resh Enterprise
The commercial product built on Resource Shell
resh Enterprise adds what an organization needs across an estate: purpose-scoped Applications, central policy administration, approval visibility, and aggregated Activity & Evidence — while execution authority stays with each managed server. It is a pre-GA design-partner preview and not generally available.
Explore the Resource Shell open-source project(opens in a new tab)

Talking to us.

resh is early, which means the person you talk to is one of the people at Miller Technology Group who are building it. The most direct way in is the design partner program. For anything else — including scepticism about the premise, which we welcome — reach us at support@reshhq.com.

Where this goes next

Categories get defined by the people who show up early.

Identity, gateways, and authorization for AI agents are filling in quickly. What happens at the resource after a call is allowed — and whether it worked — is a gap a lot of teams are hitting at once, generally the first time an agent is trusted with something that matters. If you are hitting it, we would like to hear how.