Fix agent kind

[tofarr]

• A human has tested these changes.

---

Why

Some stored data has llm in here instead of openhands. We fix this legacy data. I think this is because of changes in the schema between sdk versions.

 File "storage/org_store.py", line 53, in get_agent_settings_from_org
  File "pydantic/main.py", line 716, in model_validate
agent_kind
  
Input should be 'openhands' [type=literal_error, input_value='llm', input_type=str]
    
For further information visit https://errors.pydantic.dev/2.12/v/literal_error

How to Test

I saw this when testing the slack integration - I think it will haven whenever you start a conversation in the cloud.

Video/Screenshots

Type

• Bug fix
• Feature
• Refactor
• Breaking change
• Docs / chore

Notes

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
enterprise/storage
org_store.py					53-57
Project Total

This report was generated by python-coverage-comment-action

[all-hands-bot]

🟡 Acceptable - Prevents crashes from legacy data, but approach could be improved.

---

[RISK ASSESSMENT]

• [Overall PR] ⚠️ Risk Assessment: 🟡 MEDIUM

This bug fix prevents Pydantic validation errors when loading org settings with legacy agent_kind='llm' values. However, it masks the underlying data problem rather than fixing it through a migration. The risk is medium because: (1) database still contains invalid data, (2) no tests added to prevent regression, (3) the workaround could be bypassed if settings are saved elsewhere without this fix.

VERDICT:
✅ Worth merging: Fixes a real production crash, but should be followed up with data cleanup and tests.

KEY INSIGHT:
The fix prevents immediate crashes but leaves technical debt—consider a follow-up migration to clean the stored data and add regression tests for this legacy data path.

[all-hands-bot]

🟠 Important: This masks the underlying data problem rather than fixing it.

Issues:

• Database still contains invalid agent_kind='llm' values
• Forces value at read-time instead of cleaning up stored data
• If org settings are re-saved elsewhere without this fix, the error could return

Suggested improvements:

1. Add a one-time data migration to update all agent_kind='llm' → 'openhands' in the database
2. Add a warning log when legacy data is detected:

   if kwargs.get('agent_kind') == 'llm':
       logger.warning(f"Org {org.id} has legacy agent_kind='llm', auto-correcting to 'openhands'")

3. Document why this workaround exists in a code comment

Why this matters: Data inconsistency between stored and read values can lead to subtle bugs and makes debugging harder.

[all-hands-bot]

🟡 Suggestion: Add a test for legacy data handling.

No test verifies that orgs with agent_kind='llm' are handled correctly. Add a test like:

@pytest.mark.asyncio
async def test_get_agent_settings_from_org_handles_legacy_llm_agent_kind():
    """Legacy orgs with agent_kind='llm' should be auto-corrected to 'openhands'"""
    # Create org with legacy agent_kind='llm'
    legacy_org = Org(
        name='legacy-org',
        agent_settings={'agent_kind': 'llm', 'agent': 'CodeActAgent'}
    )
    
    # Should not raise ValidationError
    settings = OrgStore.get_agent_settings_from_org(legacy_org)
    
    # Should auto-correct to 'openhands'
    assert settings.agent_kind == 'openhands'

This prevents regression if the workaround is accidentally removed.

[all-hands-bot]

---

Improve this review? If any feedback above seems incorrect or irrelevant to this repository, you can teach the reviewer to do better:

1. Add a .agents/skills/custom-codereview-guide.md file to your branch (or edit it if one already exists) with the /codereview trigger and the context the reviewer is missing (e.g., "Security concerns about X do not apply here because Y"). See the customization docs for the required frontmatter format.
2. Re-request a review - the reviewer reads guidelines from the PR branch, so your changes take effect immediately.
3. When your PR is merged, the guideline file goes through normal code review by repository maintainers.

Resolve with AI? Install the iterate skill in your agent and run /iterate to automatically drive this PR through CI, review, and QA until it's merge-ready.

[chuckbutkus]

Looks good!