How do I try Cortex with my existing development process?

Connect one agent and give it a bounded task through your existing development process. With Cortex instructions and the required permissions, it retrieves relevant knowledge and saves useful decisions revealed by the work. You can start with an empty Account and use Modules without moving work into Cortex Issues. Repository access, tests, review, merge rules, and deployment approval remain controlled by the tools and people already responsible for them.

Choose a small pilot

Pick a real, reversible change with a clear success condition and existing checks. Explain the requirements that matter to that change as you normally would. The agent can preserve those decisions and their reasons in the relevant Module, including creating the first Module when useful knowledge emerges. You can write or edit the knowledge yourself if you prefer.

Have the agent check the Module's complete Dependency closure before sharing it. A caller allowed to Flash the Module receives the Dependencies in that result. A Module viewer grant is enough for knowledge retrieval; it does not grant Issue access or repository access.

Connect the agent through its supported plugin, MCP integration, or CLI path. Use the intended Account and verify a real Cortex call. A normal OAuth connection uses the signed-in member's identity; do not assume it creates a separately restricted Agent identity.

Tell the agent how you want knowledge changes handled. The suggested Cortex instructions let it save useful changes, briefly name the affected Modules, and explain what changed and why. You can instead ask to approve the proposed content and Dependencies before it saves. These instructions and the host's tool confirmations are separate from Cortex permissions.

Use the knowledge before implementation

When a relevant Module exists, give the agent an explicit instruction such as: “Before changing this area, Flash module-name in Cortex, read the complete result, and explain which constraints apply.” Replace the placeholder with the actual Module name. If none exists, continue the task and let the agent save useful knowledge as it emerges.

Have the agent inspect repository instructions, current code, tests, and runtime evidence as the task requires. A Module describes intended behavior; it is not a substitute for checking implementation.

Run the change through your usual branch, test, review, and deployment process. The reviewer can Flash the same Module and compare the result against the same constraints. Cortex supplies knowledge and work records; a Flash does not run CI or authorize a merge.

Evaluate the result

Check that the agent retrieved the intended context, applied the relevant decisions, and produced the evidence needed to assess the change. Record the Module versions and Flash ID with your work evidence when that trace matters. Cortex records Flash metadata, but does not automatically attach it to a commit or deployment.

If the pilot exposes missing knowledge, have the agent update the relevant Module under your chosen review preference and repeat a comparable task. Keep successful tests and review evidence separate from a claim that the agent followed every instruction.

You may use Cortex Issues to connect work to its governing Module, but a Module Flash needs only the Module name. There is no automatic synchronization with an external issue tracker in this workflow. Expand the pilot when you can explain which knowledge helped and your existing checks still establish the result's quality.