# Bootstrap a tool with an agent Start with an empty model, draft a Product Lifecycle Management or requirements ontology and views, and seed linked demo data. Source: https://docs.openeng.io/agents/bootstrap-your-tool/ Start with a blank organisation and project, then work with an agent to define a model, configure its first views and populate a small, coherent demonstration. The result is a working slice of your own engineering tool on a common branchable, secure data plane – a single source of truth for your engineering work. ## Before you start You need access to a running instance and permission to create projects and publish types. Use a fresh organisation if you want an empty ontology: projects in an organisation share its published catalogue. A coding agent with the CLI can carry the whole bootstrap workflow. Inside OpenEngineering, use the ontology agent for definitions and views, then the object agent for demo data. Publishing an in-product ontology agent's draft remains a person's action. The commands below use `oe2`. In the development checkout, start `pnpm dev:demo` and use `pnpm -s oe2` instead. That stack already has a demo world; create a fresh organisation and project for your blank model. The local sign-in path is supported; hosted CLI sign-in depends on the deployed release. ## 1. Give your coding agent the platform skill Ask your agent to read `oe2 skill` and use `oe2 help` for command discovery. In the checkout: ```sh pnpm -s oe2 skill pnpm -s oe2 help pnpm -s oe2 login pnpm -s oe2 whoami pnpm -s oe2 org list --json ``` Sign in yourself. Give the agent the instance context and the organisation you want to work in. If you need a fresh organisation, create one in the app, or ask the agent to read `oe2 help admin-sdk createOrganisation` and propose that command. Attach explicitly: ```sh oe2 org attach oe2 projects create --name "Propulsion demonstrator" oe2 projects list --json oe2 types list --project ``` Use the identifiers returned by the platform. Check that the intended organisation is active and its type catalogue is empty before continuing. ## 2. Choose a small starting model Demo World models the Europa pulse power demonstrator with two connected vocabularies. Start with the same object types and relationships, then adapt them to your programme: | Starting point | Object types | Initial connections | |---|---|---| | Product Lifecycle Management | Part, BOM line, Revision, Release | A Part itemises BOM lines; each BOM line uses a Part and can pin a Revision; a Part has Revisions; a Release releases Revisions | | Object Orientated Engineering Requirements | System, Requirement, Specification, Verification, Risk | Systems contain Systems and hold requirements, specifications, verifications and risks; requirements derive from requirements; specifications satisfy requirements; verifications verify requirements; risks threaten requirements | Both vocabularies share one project. Parts sit under their assigned System as well as appearing in the product structure. An assembly is a Part, rather than a separate object type. BOM lines hold quantity and find number for each occurrence, so one Part can be reused in several assemblies. In Demo World, the Requirements group contains System, Requirement, Specification, Verification and Risk. The Product Lifecycle Management group places Part, Revision and Release on the rail; BOM line remains available under More types. Give the agent a brief such as: > Build an Object Orientated Engineering Requirements tool using Demo World's System, Requirement, Specification, Verification and Risk model for the Europa pulse power demonstrator. Requirements need an identifier, statement, owner, priority and status. Use the statement as their display title. Use contains for the System tree and has-requirement, has-specification, has-verification and has-risk for structural placement. Keep derives, satisfies, verifies and threatens-requirement as traceability relationships. Propose the type definitions, relationship directions and initial views. Show me the plan and files before publishing anything. Use the platform's current help and validation to choose supported definitions. For Product Lifecycle Management, use this brief: > Use Demo World's Part, BOM line, Revision and Release model for the Target Positioner Assembly. Represent assemblies as Parts. Give Parts identifiers, names, make-or-buy and lifecycle state, with optional material, mass and CAD reference. BOM lines carry reference, quantity and find number. Connect Part → BOM line → Part with itemises and uses; connect Parts to Revisions with has-revision, BOM lines to pinned Revisions with pins, and Releases to Revisions with releases. Use has-part to place Parts under the target positioner System. Propose the definitions and views before publishing. Show how the same fastener appears in several assemblies without duplicating the Part. ## 3. Draft the model and initial views together Ask for an initial object view with clearly labelled property sections and connections. Configure the title and summary bindings, the navigation structure and the type's rail placement. Keep the first views small. Mirror Demo World's System tree for requirements work. For Parts, provide a Product structure view that projects Part → BOM line → Part into Part rows decorated with find number and quantity, and an alternate System structure view based on has-part. The view specification uses the platform's component vocabulary. `ObjectBody`, `PropertyList` and `ConnectionList` provide a useful starting point. The agent should validate property references and use components the running release supports. A coding agent can prepare a `draft.json` file and use: ```sh oe2 types draft open oe2 types draft revise --change-set --revision --from draft.json oe2 types draft validate --change-set --revision oe2 types draft show --change-set --project ``` Use the returned revision after each edit. Validation must report no violations. Review the type definitions and views, then accept the reviewed revision yourself or explicitly authorize your coding agent to do it: ```sh oe2 types draft accept --change-set --revision oe2 types list --project ``` The ontology agent inside the app can draft and validate this change set; you accept it in the interface. Publishing the catalogue is separate from branching engineering data. ## 4. Ask for useful demo data Specify a small dataset that demonstrates the questions your tool should answer: > Seed the approved requirements model with a small subset of Demo World's Europa pulse power demonstrator: its System hierarchy, Requirements, Specifications, Verifications and Risks. Preserve the seed's identifiers, properties and relationship directions. Include requirements without verification and a failed verification. Represent risks with severity and likelihood. Propose the selected objects and links first, then write on a named demo branch after I approve. Read back the objects and links and show me a count per type and the branch diff. Do not merge. For Product Lifecycle Management, ask for Demo World's Target Positioner Assembly and its nested assembly Parts, BOM lines, shared fasteners, Revisions and Releases. Preserve quantity and find number on BOM lines, include a pinned Revision, and show a shared fastener used in multiple assemblies. Reuse the existing target positioner System when combining both vocabularies. Have the agent read: ```sh oe2 help branches-sdk createBranch oe2 help objects-sdk mutate oe2 help objects-sdk queryObjects oe2 help objects-sdk queryGraph oe2 help branches-sdk readBranchDiff ``` It should use the published type versions, keep the returned object identities and connect those objects. On a partial failure, inspect what exists before resuming. A seed should be repeatable without duplicating records. If you want the bundled Demo World exactly, rather than an adapted model, let the agent run `oe2 demo seed --project --size standard` in a fresh project after approval. It publishes the bundled types and seeds both vocabularies; the standard dataset has 100 objects and 157 edges. `--size full` includes 31 Systems, 23 Requirements, 16 Specifications, 16 Verifications, 10 Risks, 20 Parts, 24 BOM lines, 10 Revisions and 3 Releases. This command seeds the bundled world on main; use an agent-generated seed for a custom model or a seed that needs review on a named branch. ## 5. Inspect, refine and accept For agent-generated data, open the project on the named demo branch. If you used the bundled `oe2 demo seed` command, inspect main instead; that seed has already been written there. Check: - Each promoted type is reachable, and its title and properties are readable. - The configured views show the properties and connections you requested. - The tree places objects as expected and the graph shows traceability. - The unverified requirement, failed verification and risks with their severity and likelihood are easy to find. - Counts and example links match the agent's read-back report. Ask the object agent: > Which requirements have no verification, and which Systems are they allocated to? Check the answer against the seeded examples. Adjust the model, views or seed where the workflow feels awkward. When agent-generated data is ready, submit and review its branch, then merge it. For the bundled seed on main, skip that seed-review step and create a new branch for your next engineering change. You now have a small working tool to iterate on; [change control](https://docs.openeng.io/guides/change-control.md) provides the same path for its next change. [Design your ontology and views](https://docs.openeng.io/agents/design-your-tool.md) explains the configuration workflow. [Work with engineering data](https://docs.openeng.io/agents/work-with-data.md) covers day-to-day agent use.