Skip to main content
Most Kodexa organizations build a library of shared resources — taxonomies, forms, activity plans, service bridges, document stores — that are reused across many projects. The agent makes finding and attaching those resources part of the conversation.

​
Discovery → Bind

The flow is two steps:
  1. Discover — ask what is available at the organization level.
  2. Bind — attach the resources you want into the current project.
Both are read or write operations against your existing org library. The agent does not invent new resources here; it works with what your org has already published.
Binding is atomic. Unlike resource authoring, binding does not use the draft-and-save loop — it takes effect immediately when the agent calls the tool. You can unbind just as easily if you change your mind.

​
Discovering What Your Org Has

Ask the agent broad or narrow questions: 
What taxonomies does my organization have?

List the service bridges in this organization. Which ones connect to finance systems?

Are there any activity plans for invoice processing already published?
The agent searches by name, description, and tags. You can refine (“show me only ones updated in the last quarter”) and iterate.

​
Binding A Resource

Once you have found what you want, bind it: 
Bind the Invoice taxonomy to this project.

Bind the finance-erp service bridge and the vendor-onboarding form to this project.
The agent calls the binding tool, and the resource immediately appears in this project’s bound resource list. From that point on, activity plans, tasks, and forms in this project can reference it.

​
Checking What Is Currently Bound

What's currently bound to this project?
The agent returns the project’s binding roster grouped by resource type. This is useful when you join a project mid-stream and want to know what is already wired up.

​
Unbinding

Unbind the legacy-erp service bridge from this project.
The agent will check whether the bridge is referenced by any active resource in the project before unbinding. If it is in use, the agent will tell you what is using it and ask before proceeding — unbinding a resource that is still referenced would leave dangling references behind.

​
Why Reuse Matters

Binding is the lightweight way to share resources across projects. The alternative — creating a copy of every taxonomy or bridge in every project — has obvious costs:
  • Bug fixes have to be applied N times.
  • Schema drift creeps in across projects.
  • It is hard to tell which version is “canonical”.
The agent leans heavily on discovery and binding for this reason. If you ask it to add a taxonomy that already exists at the org level, expect it to suggest binding the existing one rather than creating a near-duplicate.

​
When To Create vs Bind

SituationRight move
The org already has a taxonomy that fitsBind it
The org has something close but not quite rightBind, then ask the agent to extend it (the change applies to all projects that share it — be sure that is what you want)
This project needs a genuinely project-specific resourceCreate it (project-scoped)
You are uncertainAsk the agent — it can compare what the org has against what you described