Tools & private AI · wGrow Since 2008

Codex & Claude.
Private AI, in practice.

We work daily with Codex and Claude across desktop and command-line workflows. That experience extends into agent orchestration, memory and context management, and private AI systems designed around the information your business can use.

The purpose is practical: engineers can carry work forward, staff can find relevant company knowledge, and important actions stay within agreed permissions and review.

Working with the tools

Desktop, CLI
and coordinated agents.

Our engineering practice uses Codex and Claude for investigation, implementation, testing and review. We organise agent teams around clear tasks, shared project instructions and defined handoffs, with engineers responsible for architecture and release.

Automation needs an operating plan: which tools an agent can call, which files it can change, how it records progress, when it must stop and who reviews the result. Parallel tasks need separation and integration checks so concurrent work can be brought together safely.

For a business, the deliverables may include a configured workspace, repeatable skills, workflow automation, an evaluation suite and instructions your team can maintain. We choose the arrangement around the job and available access.

Platform references: Codex desktop workflows and Claude Code desktop and terminal use. Available features depend on the selected product and configuration.

Architecture follows the information

Different work can need
different environments.

An illustrative deployment boundary

Choose where the work runs.
Control what crosses the boundary.

Hosted development tools and private knowledge processing have different data paths and permissions.

Approved hosted environment

AI-assisted development

Suitable project material, approved for hosted processing.

  1. 01
    Approved project material

    Only code, examples and context authorised for the selected hosted service.

  2. 02
    Codex / Claude workspace

    Desktop or CLI tools with scoped files, commands and permissions.

  3. 03
    Engineer review

    Inspect changes, test the result and approve consequential actions.

Hosted processing remains subject to the service, account settings and agreed data policy.

Inside the company network

Private knowledge workflow

Local LLMs and retrieval, with controlled access and network egress.

  1. 01
    Restricted company knowledge

    Approved internal documents, records and source permissions.

  2. 02
    Permission-aware retrieval

    Retrieve the information this user and task are allowed to access.

  3. 03
    Local model and application

    Inference and retrieval run inside the agreed company environment.

  4. 04
    Authorised staff review

    Check evidence and exceptions before the result is used.

Local hardware may include DGX Spark where workload testing supports the choice.

Separate environments. No automatic data connection. Restricted sources and retrieval results are not routed to hosted tools in this design. Any proposed transfer needs an explicit decision and controls.

Architecture illustration, not a claim that Claude or Codex models run offline. Actual isolation depends on the complete application, identity, storage, logging and network configuration.

Approved hosted developer tools can assist with authorised project material. Restricted company knowledge can instead be processed through a locally hosted application, local models and retrieval within the company's network. These are separate design decisions; using a desktop interface does not make hosted inference local.

Private deployment includes the surrounding system: identity, document access, indexes, storage, tools, logs and network routes. We scope those boundaries explicitly. A local model alone does not establish an isolated workflow.

Controls that support everyday use

Limit access.
Review what can leave or change.

Identity and tool permissions

Scope accounts, filesystems, commands and integrations to the task. Separate read access from write or external-action authority. Define human approval for consequential actions.

Network and secrets

Set permitted destinations and egress rules. Keep credentials out of prompts and project content, with restricted injection or access where required. An allowed domain still needs an appropriate data policy.

Retrieved content and instructions

Treat documents, websites and tool responses as untrusted inputs. Review prompt-injection exposure and enforce permissions outside the model's instructions.

Logs and retention

Decide what prompts, outputs and traces are recorded, who may read them, what needs redaction and when it expires. Include exports, backups and monitoring in the review.

These controls reduce exposure through explicit configuration; they are not a zero-leakage guarantee. See OpenAI's Codex safety guidance and Claude Code sandboxing for product-specific capabilities and boundaries.

Continuity without an uncontrolled archive

Useful memory.
Focused context.

Agent memory needs a lifecycle. Distinguish temporary task state, a reviewed handover and longer-lived business knowledge. Record sources and ownership; define correction, expiry, deletion and access rules. Separate client or tenant knowledge so retrieval does not cross the wrong boundary.

Instructions and remembered preferences help continuity, but they do not enforce authorisation. Permissions must hold when the system retrieves information or calls a tool. Claude Code's memory documentation describes its instruction and auto-memory mechanisms; a company's wider knowledge lifecycle requires its own design.

Context management is equally deliberate. Retrieve relevant evidence, set task budgets, summarise progress and preserve decisions in structured handovers. Measure answer quality, missed information, token use, latency and cost together. Smaller context is useful when the task still works; token reduction alone is not success.

Local models and retrieval

Private AI,
sized for the workload.

We can scope local LLM and retrieval-augmented generation deployments on infrastructure including NVIDIA DGX Spark. The model, document processing, retrieval and application must fit the actual workload and company environment.

Evaluate representative documents and tasks before selecting the configuration. Model weights, runtime memory, context length and concurrent requests compete for capacity. Check response quality, retrieval permissions, failure handling and acceptable turnaround rather than promising performance from hardware specifications.

For an offline arrangement, prepare approved model weights, containers, dependencies and licences before isolation. Test the complete workflow with external connectivity disabled. Plan controlled patch and model updates, with re-evaluation before changes return to service.

NVIDIA's DGX Spark vLLM guidance explains local serving and setup considerations. DGX Spark does not make hosted Codex or Claude models run offline, and hardware alone does not guarantee data isolation.

Start with the work
and its information boundary.

Tell us which systems your people use, what information is restricted and who will operate the result. We can define the tools, private deployment, controls and knowledge transfer the engagement needs.

Discuss your environment

How we work · Training and adoption · Company cases

wGrow · Since 2008

Bring the business.
Let's shape what comes next.

Tell us about your people, systems and operating priorities. We can discuss the right starting point and a scoped path towards AI-native working.

Discuss your business

Scope, fees and responsibilities agreed
before diagnostic or implementation work.