How working together runs
Start with a recurring job your team wants to improve. Cone Red leads the change and builds with your people. Your owner checks the result and learns to run it.
Each workflow in your first quarter runs through these six phases.
For hands-on delivery, we recommend Embedded. Agree the deliverables and engineering capacity before building.
Choose a useful change with your owner. Agree the standard and business measure.
Implement the agreed workflow. Check failures and make the output inspectable.
Judge the result, practise running it and confirm readiness for handover.
Sample status-report workflow: an agent drafts each client report from the week's merged pull requests and ticket changes, in your template. The project lead edits and approves it before it goes out. Internal notes stay out, and a ticket with no update goes back to the lead.
Who moves the work forward
The same process moves through these phases. Your agreement sets the actual scope, checks and capacity.
A red bar marks the check that closes each phase.
Help name the useful result and first boundary.
Flag likely data and integration dependencies.
Describe the work, friction and real examples.
Output: A short process brief
Your owner chooses the process.Review the current tools, constraints and value of changing the process.
Inspect relevant interfaces and failure cases within the scoped work.
Explain exceptions, access boundaries and the standard people use today.
Output: A proposed change and open questions
Resolve unknowns before committing scope.Write the deliverables, capacity, measure and handover conditions.
Define technical checks, dependencies and a safe fallback.
Approve the scope and acceptance criteria.
Output: An agreement and a testable definition of useful
Owner approval before engineering.Keep the work focused on the agreed outcome.
Implement the workflow and record tests and limitations.
Provide feedback on representative work and exceptions.
Output: A reviewable workflow and test record
Failed checks return to revision.Compare completed work and the measure with the baseline.
Demonstrate the checks and address defects.
Review the output and decide whether to accept it for use.
Output: An acceptance decision with evidence
Your owner accepts or requests changes.Check the handover conditions and agree any ongoing support.
Document operation, maintenance, fallback and escalation.
Practise real work, recognise failures and demonstrate the agreed checks.
Output: An operating guide and readiness record
Hand over when agreed conditions are met.Use the evidence to decide whether to revise, accept or expand the workflow.
Your owner helps choose representative examples and exceptions. We agree how to measure the starting point before setting a target.
After building, we run the agreed checks. A failed check goes back to the engineer for revision, with the owner clarifying the standard when needed.
Monthly reporting covers completed work and the agreed business measure. An improvement target follows the baseline and scope.
We write handover conditions into the first agreement, so you know what your owner needs to learn and when we can step back.
We document how to run the workflow, recognise failures and use the fallback. Your owner practises with real work before taking over the agreed responsibilities.
Any ongoing Cone Red support or engineering follows the capacity and terms in the agreement.
Operating readiness and ownership are separate decisions. The agreement names the deliverables you keep, data exports and any software or supplier tooling you license.
Engineering appendix · for your CTO
An owned source, a reviewable draft, an explicit decision and a retrievable record work across many stacks. The repo and command-line approach below is one implementation.
A Git repository can fit teams comfortable with branches and reviews. A maintained document store or existing work system may fit others better.
Choose after checking access, versioning, sensitive data, integrations and who will maintain it.
Sample architecture. A source repository, Markdown records, YAML metadata and Git reviews provide a concrete pattern. These layers do not certify a current deployed product or require moving all company data into one place.
Owned records with dates, permissions and version history: process notes, decisions and approved material.
↓ The schema describes those records.
Required fields for identity, source, owner and state. A validator checks structure; a person checks meaning.
↓ Agents read authorised sources and produce structured drafts.
Bounded instructions and tools for extraction, drafting or critique, with a named reviewer and a stop condition.
↓ Retrieval can find related evidence as the source set grows.
Search, links and summaries point back to source records. Source changes require index and memory maintenance.
Keep access controls in the source and retrieval paths. A graph link shows a relationship to inspect; it doesn't establish that a claim is true. Read the memory reference →
These names describe project-specific commands used in the source implementation. They are not built-in features of every AI coding tool. Inspect the installed command definitions, permissions and proposed changes before using them.
| Command | Intended job | Check before use |
|---|---|---|
/init-os | Scaffold project instructions and working records. | Read the proposed files and preserve existing work. |
/init-knowledge | Describe relevant knowledge and where its sources live. | Check permissions before connecting projects. |
/init-memory | Set up durable notes and retrieval conventions. | Choose what may be retained and how to correct it. |
/init-agents | Configure roles, instructions and tools. | Review permissions and the required human approvals. |
/graphify | Build or query relationships in a source set. | Check source scope, freshness and processing costs. |
Start from a small source set and a representative task. Check the output, reviewer path and fallback before widening access or automating repeated runs.
# Example only: use your team's repo and rules
git switch -c workflow/status-reports
git diff
git status
# Run the checks for this project.
# Commit only after inspecting the output.“Draft this week's status report for the client from merged pull requests and ticket changes. Link each line to its ticket. List tickets with no update. Wait for my approval before sending.”
Use an interface the team can operate. Terminal access is an implementation choice, not a prerequisite for useful work.
Keep one bounded change on a branch. Give the reviewer the problem, changed behaviour, evidence and remaining limits. Review generated files as carefully as handwritten work.
A schema check can reject missing fields. A human still checks source fidelity, scope and permission to act. Merge and release remain separate decisions where the team requires them.
Record who decided, what changed, why and which evidence they used. Link the entry to the source and resulting work.
At the end of a work session, record completed work, unresolved questions and the next owner. Keep chat useful for discussion and move lasting decisions into the agreed record.
Inspect the source-to-ticket example and its approval rail →
Name who updates each source and how the team spots stale or contradictory material.
Test source fidelity and business meaning separately from required fields.
Have another person run the documented checks and fallback.
Start with one job the team will repeat. Add machinery when observed work justifies it.
Let a draft say unknown and return the question to its owner.
Review the baseline, results and operating load before adding another workflow.
Sequence the rollout by demonstrated readiness and dependencies. Calendar milestones belong in the agreed project plan.
Free for software companies and agencies
One workflow, three answers, one page back within three business days. No call, no access to your systems, yours to keep.