OpenClaw Integration
Let ProfileClaw own context while OpenClaw owns action
The cleanest integration boundary is simple: ProfileClaw prepares durable career context, while OpenClaw handles planning, tool orchestration, and user-facing action on top of that layer.
The integration works best when each layer has one clear job
ProfileClaw should not become the whole agent. It should become the context provider the agent can trust over time.
Layer responsibilities
Keep each system opinionated about only the part it should own.
ProfileClaw
Owns identity, context, career structure, and contract-level retrieval surfaces.
- Start sessions from Context API instead of chat-history reconstruction.
- Escalate to prediction or reasoning only when needed.
- Use it as the durable source of career state.
OpenClaw
Owns planning, tool routing, conversation flow, and execution loops.
- Keep tool choice and orchestration in the agent runtime.
- Treat ProfileClaw responses as trusted inputs, not direct UI scripts.
- Resume workflows through explicit orchestration logic.
Shared Boundary
The handoff between the systems should stay inspectable and stable.
- Use docs for architecture posture.
- Use Reference for exact field inspection.
- Use OpenAPI for generated tooling and tests.
Use ProfileClaw as the context provider
OpenClaw should begin from a ProfileClaw context read rather than trying to rebuild the same career identity from chat history every time.
- Read context at session start or before high-stakes actions.
- Use the summary as the grounding layer for prompts and tool routing.
- Keep the first integration on compact reads unless deeper structure is proven necessary.
Branch by job after the context layer is loaded
Once the agent has a stable user picture, it can select narrower ProfileClaw calls based on real task intent instead of endpoint familiarity.
- Use prediction for future-path exploration.
- Use reasoning for deeper narrative analysis.
- Use alerts or webhooks when the workflow must stay active over time.
Boundary Comparison
A healthy integration keeps context and action responsibilities separate.
| Layer | Should own | Should not own |
|---|---|---|
| ProfileClaw | Context retrieval, normalized career structure, and contract surfaces. | Conversation control or UI-level execution planning. |
| OpenClaw | Workflow orchestration, tool selection, and user-facing action loops. | Long-term career identity reconstruction from scratch. |
| Integration boundary | Typed requests, clear routing, and observable handoffs. | Implicit prompt-only coupling between the systems. |
Decision Matrix
Use these choices when designing or debugging the integration boundary.
Situation
The agent needs a stable career picture
Action
Read Context API before choosing the next tool.
Why
It provides the highest-signal shared user model.
Situation
The workflow becomes future-facing or explanatory
Action
Branch into prediction or reasoning after context.
Why
Those APIs are made for decision and explanation depth.
Situation
The integration becomes hard to reason about
Action
Re-check which layer owns context and which owns action.
Why
Boundary drift is a common source of hidden complexity.
Minimal integration path
The current public self-serve flow starts with a read-only Context API key. Deeper scopes for reasoning, prediction, or webhooks are still private beta / manual request, so keep the first OpenClaw-style integration on context reads.
curl "https://api.profileclaw.com/api/v1/context" -H "Authorization: Bearer $PROFILECLAW_API_KEY"curl "https://api.profileclaw.com/api/v1/context?expand=careerGraph&careerGraph=summary" -H "Authorization: Bearer $PROFILECLAW_API_KEY"Next surfaces
After the architecture boundary is clear, inspect agent workflow and contract details.